Quem disse que a hierarquia está no controle?

“Especialização, hierarquia e centralização, estes fenômenos aparecem em auto-organizações constituídas por grande número de indivíduos.” Com essa afirmação, Edgar Morin, no livro O método 2 – A natureza da natureza,  reforça a ideia de que a auto-organização é uma característica natural (e padrão) nos sistemas vivos.

Numa visão epistemológica, o termo auto-organização pode ser considerado um pleonasmo.  A organização é um fenômeno originado por influência  das inter-relações (associações, ligações, combinações, fluxos contrários, acasos) entre as partes de um sistema complexo. Um sistema é um conjunto de partes que interagem para gerar algum resultado.  E somente se olharmos unicamente para essas partes, sem as interações (movimento), veremos  que somente nesse momento temos um estado de ordem. Mas a partir do momento que as partes começam a interagir, automaticamente se estabelece um estado desordenado.

Olhando para a ciência, podemos explicar essa relação entre a ordem e a desordem pelos olhos da termodinâmica. Nesse ponto, as partes só estarão ordenadas quando não há troca de energia entre elas.  Portanto, se não há troca de energia, não temos um sistema.  Um sistema nasce a partir da própria organização. Ainda segundo Edgar Morin: “Para que haja organização, é preciso interações. Para que haja interações é preciso encontro, para que haja encontro é preciso desordem (agitação, turbulência)”. Ou seja, cada parte individual precisa se movimentar (sair da ordem) para dar início ao próprio fenômeno da organização.  Esse fenômeno pode ser chamado de “desordem organizadora”.

Morin reforça esse pensamento por meio do princípio dialógico que rege os sistemas complexos.  Esse princípio mostra que para sobreviver, um sistema precisa fazer associação de coisas (partes) que ao mesmo tempo  são complementares e antagônicas. Como essas partes estão solidariamente conectadas,  em termos práticos, um sistema sempre está fazendo um espécie de sincretismo para que o mesmo possa evoluir. Dessa forma, ordem e desordem, competem e cooperam ao mesmo tempo para fazer que um sistema se mantenha saudável.

Reconhecendo essa essência termodinâmica que gera a complexidade, é possível construir a ideia de que a ordem é um estado efêmero.  Logo, qualquer tentativa de ordenar esse dinamismo, pode ser considerado uma vã iniciativa.  O sistema está sempre se auto-organizando (ou melhor, se organizando).

Retomando a aplicação desse pensamento ao mundo corporativo, é possível entender também que a  hierarquia  é uma ilusão.  Efeitos como hierarquia,  especialização e centralização são gerados, curiosamente, pelo próprio jogo de interações e emergências feitas pela auto-organização.  Se olharmos para história da humanidade, veremos que antropologicamente esses conceitos emergiram a partir da interação de grandes grupos de pessoas.  Em  um dado momento da história humana, foi necessário centralizar os recursos e especializar atividades.  A partir dessa centralização e especialização, a humanidade teve que centralizar decisões. Nesse momento, temos então o nascimento das hierarquias.

Contudo, a hierarquia é um estado frágil. Com todo o dinamismo, imprevisibilidade singularidades, acasos e interconexões, um sistema complexo não pode ser controlado de maneira centralizada. Na verdade, qualquer iniciativa de controle advindo da hierarquização, é apenas uma forma de reagir aos próprios movimentos gerados pelo sistema.

Nesse ponto, a gestão nunca conseguirá ser mais poderosa que a própria organização. E parafraseando o pensamento do famoso artigo Dancing with Systems,  de Donella Meadows: A gestão precisa aprender a dançar conforme a complexidade, ou seja, não é a gestão que rege a sistema, mas sim, o contrário.

Num artigo no blog da Harvard Business Review, Tim Kastelle aborda a ideia que a hierarquia é superestimada (Hierarchy Is Overrated). O ponto central de todo esse texto de Kastelle corrobora e reforça os pensamentos apresentados nesse meu texto.  De fato,  existe uma tendência natural em acreditar que hierarquização, especialização e centralização, são a melhor solução para organizar uma empresa. Hoje já existem várias empresas (nacionais e internacionais) que estão experimentando ideias que questionam essa crença.  É importante ressaltar que a Gestão 3.0 em si, não preconiza a inexistência total de hierarquizações ou especializações, porém, é necessário e saudável entender que  uma hierarquia é uma forma míope de representar um sistema complexo. E como uma forma míope, é ineficaz ao tentar controlar e prever todo e qualquer comportamento das pessoas que fazem parte daquele sistema social.

Finalizo esse texto destacando que a intenção de todos os pensamentos acima, não é defender ou evangelizar a complexidade como algo naturalmente bom.  Na verdade a complexidade não é a solução, é um problema inextricável e insolúvel. Cabe a nós termos que aprender a lidar/conviver com a complexidade. Da mesma forma, a próprio  auto-organização não deve ser considerada como sendo boa, nem ruim. A auto-organização é um fenômeno. É uma característica natural de um sistema complexo.  A auto-organização, por si só, pode levar o sistema a algo bom, mas também pode levar o sistema a algo ruim. A diferença está nas restrições criadas e retroalimentadas pelo próprio sistema (e ecossistema). Cabe então a gestão, não criar as restrições em si, mas sim, identificar e torná-las explícitas para que o sistema consiga de auto-organizar (organizar) de forma saudável.

6 Comentários »

Categorias deste post

How to Build Great Teams, Management 3.0, Mudança organizacional

Introdução do Quadrante de Teste Ágil

Uma pergunta muito comum, quase sempre vinda de um profissional de testes, dento da linha ágil é: como vou testar no Scrum?
Essa pergunta geralmente é feita por falta de conhecimento em agilidade, e a resposta é que não existe fórmulas, padrões ou receitas de bolo de testar utilizando Scrum , XP, Kaban ou qualquer prática ágil para desenvolver um software.

Muitos tem sede de ter um processo, uma fórmula para trabalhar com testes em agilidade, mas isso é mais fácil do que imaginamos…
Mas antes vamos conceituar um pouco o porque disso.

 

Conceituação no modelo tradicional

No modelo que podemos chamar de tradicional temos duas abordagens distintas com algumas dimensões, além de separação clara de papéis e atividades. Enquanto parte dos profissionais de análise de negócio, arquitetura e gestão trabalhavam no desenvolvimento dos requisitos, o testador criava uma série de documentos para verificar se os requisitos estavam de acordo com o que foi pedido, mas muita coisa era perdida e o foco era (ou ainda é em algumas empresas) em pesadas documentações e checklists.
O Modelo V de Testes foi um guia por muito tempo neste ponto, trazendo quatro níveis e chamando estas etapas de Verificação: requisitos, análise, arquitetura e codificação (este compartilhado com o próximo grupo de nível).
Neste ponto os testadores também criavam os casos de teste, quando o time já estava na fase “codificação”

Quando chegava a fase em que um grupo de funcionalidades já estava apta a ser testada entramos na fase de validação, que consiste nos níveis: unidade, integração, teste a aceitação. Neste ponto começam os testes como conhecemos no modelo tradicional.

O Modelo V de testes foi utilizado por muitos como um guia para entender estes níveis e o que poderíamos fazer em cada um, e esta é a forma correta de utilizá-lo, mas remetendo sempre a termos testes no final do processo.

E como isso funciona dentro do Ágil?

 

O Quadrante de Teste Ágil

Já sabemos pelo post anterior o que é Agile Testing. Agora iremos aprender qual o guia que temos quando utilizamos práticas ágeis no projeto e queremos aplicar alguma abordagem ou técnica de teste.

O Quadrante de Teste Ágil foi criado por Brian Marick que introduziu uma série de termos para diferentes categorias de teste para alcançar diferentes propósitos através de um diagrama.

Quadrante Teste Agil

Este diagrama, dividido em quatro quadrantes reflete diferentes razões de teste. Nele já uma matriz dividindo testes que suportam o time e criticam o produto, que é dividido em foco no negócio ou foco em tecnologia.

Vale lembra desde agora que o quadrante é um guia, e não um processo!

Testes que suportam o time

Podemos dizer que os testes que suportam o time são os que ajudam os desenvolvedores, não somente testers, enquanto o produto é desenvolvido. Estes testes são mais voltados a qualidade e entendimento dos requisitos e arquitetura do que em testes como conhecemos de forma funcional.

Quadrante 1

Representa, basicamente, a principal prática de desenvolvimento ágil:  TDD – Test Driven Development.
Dentro deste quadrante temos duas práticas: teste de unidade, que valida uma pequena parte da aplicação como objetos e/ou métodos, e testes de componente que valida partes maiores da aplicação como um grupo de classes que provê o mesmo serviço. São usualmente desenvolvidos com ferramentas xUnit e medem a qualidade interna do produto.
Ao utilizar a técnica de TDD o programador pode desenvolver uma funcionalidade sem se preocupar em posteriormente alterar qualquer parte da aplicação, ajudando assim a tomar melhor decisões de arquitetura e design.
Não são destinados ao cliente, pois o cliente não irá entender os aspectos internos do desenvolvimento e não devem ser negociáveis com o cliente, pois a qualidade do código deve sempre existir e não ser negligenciada. Os testes desenvolvidos usualmente executados dentro de uma abordagem de Integração Contínua para prover um rápido feedback da qualidade do código.

Quadrante 2

Este quadrante também suporta o time de desenvolvimento, continua guiando o desenvolvimento, mas de uma maneira mais alto-nível focando mais em testes que o cliente entenda, onde este define a qualidade externa de que ele precisa.
Aqui o cliente define exemplos que serão usados para um entendimento maior do funcionamento da aplicação, e são escritos de forma com que o cliente ou papéis ligados a negócio entendam. Todo o teste executado aqui tem um foco no funcionamento do produto e alguns deles podem até mesmo ter uma pequena duplicação com alguns testes criados no Quadrante 1.
Testes testes focados no negócio também podem ser automatizados e, usualmente, a técnica de BDD – Behavior Driven Development é utilizada na escrita e execução automatizada destes exemplos.

Neste quadrante também podemos utilizar de pessoas com conhecimentos em UX para que, através de mockups e wireframes, o cliente possa validar a interface gráfica antes que o time comece a desenvolver esta camada.

Testes que criticam o produto

O termo “criticam” aqui não é apenas de forma destrutiva, mas também relacionados a melhoria. O foco é saber como iremos aprender a melhorar o produto, escrevendo, se necessário, mais critérios e exemplos.

Quadrante 3

As vezes mesmo criando diversos mecanismos para assegurar que estamos atendendo a necessidade do cliente através de critérios e/ou exemplos, pode acontecer de não atendermos realmente aquele desejo, ou mesmo o teste unitário e o teste através do BDD podem não ter um real valor.
Neste quadrante iremos realmente criticar o produto e executa-lo como um usuário real usando nosso conhecimento e intuição na utilização da aplicação. O cliente pode executar este tipo de tarefa, usualmente chamada de UAT – User Acceptance Testing, dando um feedback mais preciso, aceitando a funcionalidade, analisando possíveis novas funcionalidades. Esta ação pode ser também um dos critérios de DoD – Definition of Done de uma funcionalidade.
O ponto central deste quadrante, além do UAT, são os testes exploratórios. Utilizando esta técnica qualquer membro do time é capaz de, simultaneamente, aprender sobre a aplicação e executar mais testes, usando o feedback do último teste para a execução dos próximos e também é capaz de extrair novos critérios, sempre observando o comportamento da aplicação.

Quadrante 4

Os testes neste quadrante são os mais técnicos e criticam o produto em termos de performance, carga e segurança.
Nos dias de hoje negligenciar aspectos como performance podem tirar a vantagem competitiva de um cliente. Geralmente já conhecemos aspectos relacionados a performance e segurança quando refinamos algumas User Stories.
As técnicas aplicadas a performance, carga e segurança vão desde os níveis mais baixos (como um profiling de código) como a utilização de ferramentas que simulam diversos usuários simultaneamente.

Bom, agora você já sabe, conceitualmente, um pouco deste guia para iniciarmos atividades de teste de software dentro de uma equipe ágil. Vale ressaltar que todas as técnicas de teste e abordagens podem ser utilizadas, pois o quadrante é um guia e não um padrão 😉

2 Comentários »

Categorias deste post

Agile, Qualidade, Técnico, Time de desenvolvimento