quarta-feira, 9 de setembro de 2009

Que idioma devemos utilizar em nosso código inglês ou português. Como devo tratar a expressividade do código e a ubiquitous-language.

Já faz algum tempo que discutimos em meu trabalho sobre que idioma utilizar no código, português ou inglês. Entretanto, meu novo brinquedo me motivou a escrever este post sobre Ubiquitous Language e legibilidade de código. Espero que realmente seja útil para alguem, e que gere alguns bons comentários (Ninguém nunca comentou no meu blog)-: então vamos lá...

Para desenvolver software, necessitamos de um conhecimento sobre o domínio do problema. Como desenvolvedores de software, normalmente, não são especialistas no negócio do cliente, logo se faz necessário a formação de uma equipe multidiciplinar contentendo analistas de negócio, clientes, gerentes de projeto e etc. Além das habilidades, ferramentas e técnicas, as pessoas envolvidas de algum modo no desenvolvimento do software devem estar preparadas para trabalhar em equipe e lidar com os diferentes aspectos e pontos de vista. Há de se buscar sinergia, comunicação e muita disciplina, sem prejudicar o nível de participação e envolvimento das pessoas com a missão recebida.

Para solucionar o problema de comunicação entre esta equipe multidiciplinar e melhorar a qualidade interna do código desenvolvido, Eric Evans em seu livro Domain-Driven Design: Tackling Complexity in the Heart of Software (Hardcover) propõem uma solução denominada Ubiquitous Language.
Basicamente é um dos conceitos que o DDD utiliza, que tem como finalidade: “falar” a língua do usuário/cliente. Manter uma única linguagem de domínio que seja entendível tanto para os desenvolvedores quanto para o cliente. Ubiquitous Language não é uma linguagem utilizada apenas no código, porém em qualquer atividade (documentação, reunião, especificação, testes, código, conversas entre a equipe e especialistas etc) durante todo o desenvolvimento do software. Seu modelo tem que possuir as palavras chaves do domínio do cliente, isto facilita o entendimento de todos os envolvidos do software.

Para conhecer mais sobre ubiquitous language ou DDD sugiro ler o livro. Eu não li, mas minha filha número 4 leu e falou que é muito bom.
Como o ubiquitous language, DDD e juntamente com DSL (Domain Specific Languages) em voga a legibilidade e expressividade do código e ainda prometem dar muito o que falar, parece que a gente fica cada dia mais influenciado pela tendência de deixar o código o mais próximo possível da linguagem de negócio. O código deve estar o mais claro possível, isto é, sem interferências geradas pela sintaxe da linguagem.

Assim, para nós utilizarmos a linguagem do cliente (como estamos no Brasil), deveríamos utilizar o português em nosso código. No entanto, quando falamos em linguagem de programação, somente temos opções em inglês, transformando nosso código em uma tremenda salada de fruta.

Entretanto, ontem descobri que em python poderia traduzir suas palavras reservadas (magia negra) e escrevi um modulo para que acrescenta as palavras chave da linguagem em português, colocando todo meu código em português. Para utilizar o módulo, basta acrescentar o cabeçalho "#encode: pt-br" o inicio do arquivo python. Com isto podemos escrever:


#encode: pt-br

imprima "numeros pares:"
para cada numero na faixa(1, 10):
    se nao numero % 2:
        imprima numero,





Para minha surpresa (minto, sabia que iriam falar isso) meus colegas perguntaram para que vou escrever código python em português?
Mas vamos a resposta... como jah descrito no texto, legibilidade de código faz toda a diferença. As palavras que vc utiliza para se expressar, muda toda sua forma de pensar. Quando vc traduz seu modelo para o inglês, sua interpretação raramente será exatamente a mesma de outra pessoa, logo vc deveria em seu código, utilizar os mesmos conceitos do usuário/cliente e envolvidos no projeto (normalmente, porem nem sempre o pt-br). A tradução das palavra reservadas do python, somente evita o tutifrute de idiomas. Para resolver a bateria de módulos inclusos no python, simplesmente traduza em seu importe. Por exemplo:
#encode: pt-br
de os importe path como caminho


Para entender melhor o que eu estou falando e testar o inglês dos leitores, vejamos alguns exemplos:

Qual das duas palavras em inglês quer dizer faculdade, college ou Faculty?
A grande maioria das pessoas deve ter respondido college, o que esta correto. Entretanto, faculty tambem esta correto, onde este significa faculdade de faculdade mental.
A tradução sempre é um problema, vejamos a palavra "free", qual das palavras abaixo poderia ser uma tradução?
gratuitamente, aforrar, grátis, libertar, desembaraçado, livrar, espontâneo, soltar, desembaraçar, desobstruir, emancipado, desentupir, franquear, eximir, emancipar, desobrigar, abrir, aliviado, livre, liberto, desprendido, gratuito, absolvido, autônomo, desobstruído, independente, isento.
Para a surpresa de alguns, todas estas palavras poderiam ser possíveis traduções para free.
Qual destas palavras quer dizer fisico: physic, psychic, physics, physicist, physician, physique?
Físico em português possui dois sentidos, o profissional de física e relacionado a aparência. Nas opções, a primeira palavra quer dizer lachante, a segunda quer dizer vidente, a terceira quer dizer a fisica a ciência, physicist significa fisico, physician é médico e physique quer dizer fisico de aparência.
Continuando com a brincadeira, qual destas palavras não quer dizer tempo: time, weather, tempo, tense:
A palavra “tempo” pode ser vertida para a língua inglesa de três maneiras diferentes: quando quiser se referir à medida cronológica, use “TIME” Ao se referir às condições climáticas, a opção correta é “WEATHER” Para descrever um tempo verbal, use “TENSE”. Em inglês, a palavra “TEMPO”, de origem italiana, é usada em música e significa andamento, no sentido de rítimo, o tempo da música.

Nem sempre vou utilizar o português para programar em python. Entretanto, como a maioria de meus software tem âmbito nacional, este novo módulo será muito utilizado.

sábado, 20 de junho de 2009

Domiain Specific Languages (DSL)

O acrônimo "DSL" quer dizer domain-specific language ou linguagem de domínio específico. Ao contrário de uma linguagem de propósito geral como Python, Ruby, C# ou Java, que pode implementar qualquer coisa, uma DSL está restrita um domínio como: consulta (SQL), formatação de texto (HTML), estruturação de dados (XML), automatização de testes (Cucumber) entre outros exemplos.

Para explicar o significado de DSL nos voltamos ao fundamentos.
- O que seria uma linguagem?
Linguagem, de acordo com o dicionário Michaelis, é um conjunto de sinais que serve o homem para exprimir suas idéias; agregado de palavras e métodos de os combinar usados por um povo; idioma, língua. Logo, uma linguagem especifica de domínio ao contrário de uma linguagem genérica, caracteriza-se por certas peculiaridades de palavras e métodos de uma área específica de interesse e seus domínios gramaticais ou léxicas para exprimir suas idéias; dialeto.

O uso de DSL visa tratar um problema específico, dentro de um domínio específico, através da criação de uma linguagem própria para o mesmo. Neste contexto, existem diversos tipos de DSL como por exemplo externas ou internas. Uma DSL externa geralmente pode ser interpretadas por uma linguagem de uso geral ou compiladas para obter uma linguagem mas natural ao seu domínio. Um exemplo que expressa bem esse conceito é o pyccuracy, uma ferramente de teste para aplicar bdd em uma linguagem que um usuário/cliente possa ler.

Em contrapartida, uma DSL internal normalmente é voltada para os próprios programadores realizar uma determinada área de aplicação. Uma DSL interna torna o código extremamente legível, ou seja, o código é fácil de ser lido e entendido por uma pessoa que entende sobre seu domínio, tornando o código muitas vs mais curto e menos cansativo de escrever.

Qualquer linguagem pode-se criar uma linguagem de domínio interna, em maior ou menor grau, sendo que linguagens dinâmicas existem certas características que facilitam esse tipo de programação. Um forte protocolo para objetos, uma sintaxe flexível e a capacidade de interceptar características da linguagem são essenciais para o aproveitamento máximo de uma DSL.

Uma DSL interna que estou desenvolvendo no momento é uma linguagem de consulta "hurrySQL" para o grok. Este framework utiliza um banco de dados OO (ZODB) e estou desenvolvendo uma DSL interna semelhante ao SQL para consultar os objetos python pela sua interface.

Exemplo:
>>> from hurrySQL import SELECT
>>> from RH.interface import IPessoa
>>>
>>> SELECT(IPessoa.nome, IPessoa.idade).FROM(IPessoa).WHERE(IPessoa.idade > 18)
[("Gustavo Rezende", 28), ("Paula Tejando", 22)]

Uma derivação desta DSL será para criação de tabelas HTML.
Exemplo:

>>> TABLE(IPessoa.nome, IPessoa.idade).FROM(IPessoa).WHERE(IPessoa.idade > 18)
<table>
    <tr>
        <td>Gustavo Rezende</td>
        <td>28</td>
    </tr>
    <tr>
        <td>Paula Tejando</td>
        <td>22</td>
    </tr>
</table>

Repare que estou utilizando a sintaxe do python para simular outra linguagem (SQL). Ou seja, um dialeto python diferente para um problema especifico.

Um outro exemplo de DSL interna que fiz que estou disponibilizando junto com este post é para escrever HTML em python. Para demonstrar a diferença entre uma api comum e uma DSL vou criar um XHTML com o BeautifuSoup do python.

Código equivalente não usando DSL:

>>> pag = BeautifulSoup()
>>> html = Tag(pag,"html")
>>> pag.append(html)
>>> head = Tag(pag, 'head')
>>> title = Tag(pag, 'title')
>>> title.append("Teste BeautifuSoup")
>>> head.append(title)
>>> html.append(head)
>>> body = Tag(pag, 'body')
>>> h1 = Tag(pag, 'h1',attrs=[("id","title")])
>>> h1.append("Teste BeautifulSoup")
>>> body.append(h1)
>>> p = Tag(pag, 'p',attrs=[("id","content")])
>>> p.append("Conteúdo da página")
>>> body.append(p)
>>> html.append(body)
>>> html
<html>
 <head>
  <title>
   Teste BeautifuSoup
  </title>
 </head>
 <body id="content">
  <h1 id="title">
   Teste pyhtmdsl
  </h1>
  <p id="content">
   Conteúdo da página
  </p>
 </body>
</html>


Utilizando a DSL (pyhtmdsl):

>>> HTML(
...     Head(
...         Title("Teste pyhtmdsl")),
...     Body(id="content")(
...         H1(id="title")
...             ("Teste pyhtmdsl"),
...         P(id="content")
...             ("Conteúdo da página")))
<html>
 <head>
  <title>
   Teste pyhtmdsl
  </title>
 </head>
 <body id="content">
  <h1 id="title">
   Teste pyhtmdsl
  </h1>
  <p id="content">
   Conteúdo da página
  </p>
 </body>
</html>

domingo, 14 de junho de 2009

Desdobrando o Manifesto Ágil: O funcionamento do software acima de documentação abrangente (versão Alpha)

O manifesto contém quatro princípios fundamentais que valorizam:

  • Os indivíduos e suas interações acima de procedimentos e ferramentas;

  • O funcionamento do software acima de documentação abrangente;

  • A colaboração dos clientes acima da negociação de contratos;

  • A capacidade de resposta à mudanças acima de um plano pré-estabelecido

Este texto esta em versão Alpha e é o segundo de uma série de 4 posts fundamentando e mostrando os alicerces do manifesto Ágil.


O funcionamento do software

acima de documentação abrangente


Para explicar esta citação, volto aos princípios do "Lean Thinking", onde se encaixa muito bem aqui a “Cadeia de Valor”, a formação da estrutura do valor está vinculada à percepção do cliente ao produto/serviço e atender às suas necessidades exatamente com o que eles desejam.


MUDA é uma palavra japonesa que você não pode deixar de conhecer. Soa estranho, pois muda significa “desperdício”, especificamente, qualquer atividade humana que absorve recursos, mas não cria valor: erros que exigem retificação, produção de artefatos que ninguém deseja, e acúmulo de artefatos em espéra, etapas de processamento que, na verdade, não são necessárias, ..., grupos de pessoas em uma atividade posterior, que ficam esperando porque uma atividade anterior não foi realizada dentro do prazo, e bens e serviços que não atendem às necessidades do cliente.” (Womack et al.1998, p. 3)

Um dos fundamento do Pensamento Enxuto é a eliminação de desperdício, redução de estágios do processo (alguns cargos “como analista” ou processos não deveriam nem existir) e a delegação e transferência do máximo de tarefas e responsabilidades, tanto da gerência quanto da mão-de-obra indireta – manutenção, preparação ferramental, qualidade, etc...; para os trabalhadores que realmente agregam valor ao produto ou serviço.

A maioria dos artefatos/documentação sugeridas pela Engenharia de Software tradicional não tem valor algum para o cliente. Muitos dos artefatos/documentação são produzidos simplesmente para transcrever o que um mau programador deve codificar, sendo que o código é o que realmente agrega valor ao cliente.

Segundo Womack et al. (1998), da mesma forma que “as atividades que não podem ser medidas não podem ser adequadamente gerenciadas”, as atividades usadas para criar um bem ou serviço que não possam ser precisamente identificadas, analisadas e associadas, igualmente, não poderiam ser questionadas, melhoradas ou até eliminadas. Daí a importância de se gerenciar as cadeias de valor específicas para bens ou serviços específicos, pois conforme o autor as atividades que compõem estas cadeias podem ser divididas nas seguintes categorias:

  • aquelas que realmente criam valor, o qual é percebido pelo cliente;

  • aquelas que não criam valor, no entanto são necessárias para os sistemas de desenvolvimento ou produção de um produto ou serviço;

  • aquelas que não criam valor para o cliente, as quais podem e devem ser imediatamente eliminadas.

Para Porter et al. (1999), o conceito de “cadeia de valor” identifica as várias atividades que a empresa desempenha para executar o seu negócio. Estas atividades, diferenciadas do ponto de vista tecnológico e econômico, são chamadas de “atividades de valor” e vão gerar o valor, que é mensurado através do preço que os compradores estão dispostos a pagar pelo produto ou serviço. “O negócio é rentável quando o valor que cria é superior ao custo do desempenho das atividades de valor”. Logo, as atividades e o custo de gerar qualquer tipo de documentação devem ser avaliadas pelo desejo do cliente.

Vale aqui citar alguns avanços da tecnologia, ferramentas e técnicas que são usados nas metodologias Ágeis e reduzem enormemente a necessidade de uma documentação abrangente. BDD, TDD, DDD, ubiquitous language são ótimos exemplos destes avanços. Dentre outras avanços, temos também outra vertente; geração de documentação a partir do código. Estas tecnologias trazem uma enorme vantagem competitiva pois este tipo de documentação tem custo zero e nunca fica desatualizada.

sexta-feira, 12 de junho de 2009

O fracasso da engenharia de software tradicional.

O conceito de Engenharia de Software surgiu inicialmente em uma conferência organizada para discutir o que foi então chamada de crise de software. Este post tem como objetivo mostrar o fracasso da engenharia de sofware tradicional mostrando que pouco mudou desde então. O Standish Group, publicou uma série de relatórios de caos descrevendo embaraçosamente os projetos de TI e suas baixas taxas de sucesso, começando com uma péssima taxa de 16 por cento em 1994 e uma melhoria para ridículos 34 por cento em 2006 . Outras pesquisas mostram que nossa Engenharia de Software não mudou muito a crise de software.

As estatísticas da Scientific American [filho, 2000] mostram que o tempo realizado dos projetos de software excede em 50% o tempo planejado no cronograma do projeto.

O standish Groups relatou em 1994 [Standish, 1994] que apenas 16% dos projetos de software atingem o seu objetivo dentro do cronograma e do orçamento previstos.

Os dados de 2001 do Standish Groups [Standish, 2001] mostram as seguintes estatísticas: 27% dos projetos de software são finalizados no tempo e custos previstos; 40% dos projetos são cancelados antes de finalizarem; 50% dos projetos custam em média 108% a mais da estimativa original; em 2006 a Standish O CHAOS Report [Standish, 2006] apresentou os seguintes dados: apenas 34% dos projetos são bem sucedidos.

Cabe salientar que ocorreu uma pequena melhoria nas estatísticas de projetos que terminam dentro do prazo (cronograma) e orçamento previstos do Standish Group de 1994 (16%) , 2001 (27%) e 2006 (34%). Entretando, a melhoria ainda se mostra frustrante e seus índices um tanto embaraçador.

Note que se um projeto é subestimado, mesmo utilizando-se os melhores métodos para a elicitação de requisitos, design, implementação e testes, o projeto corre um alto risco (40%) de ser cancelado.

O principal risco que afeta os projetos de software subestimados é o de pressão excessiva do cronograma, o qual pode forçar o término prematuro do projeto, colocando em risco a qualidade e a funcionalidade do projeto [Jones, 1994]. Entre as possíveis conseqüências desse risco temos: cancelamento do projeto, baixa moral da equipe, baixa qualidade, atrasos de cronograma, custos excessivos devido a um grande número de horas extras e atritos entre o gerente e a equipe [Hazan, 1999].

Nas pesquisas aqui explanadas, não são contempladas os projetos que não obtiveram êxito no processo de licitação ou as propostas que não foram aceitas por algum contratante devido a sua estimativa superestimada em seu orçamento.



Outra pesquisa muito conhecida no mundo ágil é de utilização das funcionalidades de um software. Esta estatística demonstra que 64% da funcionalidades de um software típico raramente ou nunca são usadas, salientando para um grade desperdício de código desenvolvido.

Estas pesquisas demonstram que, nossa área de Desenvolvimento de Software, não somente não fazemos software direito mas também fazemos as coisas erradas.

A solução para tudo isto fica para os próximos posts...










segunda-feira, 8 de junho de 2009

Desdobrando o Manifesto Ágil: Os indivíduos e suas interações acima de procedimentos e ferramentas (versão Alpha)

O manifesto contém quatro princípios fundamentais que valorizam:
  • Os indivíduos e suas interações acima de procedimentos e ferramentas;

  • O funcionamento do software acima de documentação abrangente;

  • A colaboração dos clientes acima da negociação de contratos;

  • A capacidade de resposta à mudanças acima de um plano pré-estabelecido

Este texto esta em versão Alpha e é o primeiro de uma série de 4 posts fundamentando e mostrando os alicerces do manifesto Ágil.



Os indivíduos e suas interações
acima de procedimentos e ferramentas.


A evolução deste conceito coincide com a evolução das teorias das organizações, modificando os paradigmas da individualização do trabalho, e da especialização dos operários/peões colaboradores numa determinada etapa do processo de desenvolvimento.

O Desenvolvimento de software sofre com grandes e rápidas mudanças, tornando-se cada vez mais difícil prever o efeito que a mudança tecnológica terá nas atividades vinculadas à administração da produção e desenvolvimento. Esta dinâmica exige que as empresas ajustem seus modelos a fim de obter maior eficácia nas suas operações.

Dessa forma, a organização inovativa não pode basear-se em qualquer forma de padronizar a coordenação, ou seja, deve evitar todas as formas induzidas pela estrutura burocrática, especialmente a divisão de trabalho, a diferenciação das unidades, os comportamentos formalizados, a ênfase nos sistemas de planejamento e de controle, devendo permanecer flexível. É significativa a evolução do conhecimento no que se refere a administração e organização do trabalho, considerando as idéias dos pioneiros Taylor e Fayol até as teorias mais modernas e práticas atuais das organizações.


“ O principal argumento contra a abordagem tradicional recai sobre a própria condição que ela visa promover, ou seja, a independência entre os estágios produtivos. Quando um problema ocorre em dado estágio, este problema não se torna imediatamente aparente em outros estágios do sistema. A responsabilidade pera resolução do problema estará centralizada no pessoal desse estágio, fazendo com que as consequências do problema não sejam transmitidas ao resto do sistema.”

Administração da Produção. SLACK, Nigel.


Uma das filosofias inspiradas pelo movimento Ágil é o "Lean Thinking". Mo "Pensamento Enxuto", Womack et al.(1992) acreditam que uma empresa realmente Lean possui duas características organizacionais fundamentais:


  • delegação e transferência do máximo de tarefas e responsabilidades, tanto da gerência quanto da mão-de-obra indireta – manutenção, preparação ferramental, qualidade, etc...- para os trabalhadores que realmente agregam valor ao produto;
  • existência de um sistema de detecção de defeitos que relaciona cada irregularidade com “sua derradeira causa”, evitando, desta forma, sua propagação e reincidência.


A partir destas novas visões, o trabalho em grupo passa a ser bem aceito e surgem também os grupos semi-autónomos, que de acordo com Herbst, (1974 apud MARX, 1997) é reconhecido como um grupo que se torna plenamente responsável pela produção e que não tem atribuições definidas pela gerência, mas se auto-organiza e divide as tarefas entre si, cabendo à liderança a intermediação desse grupo com o meio externo. Veja que, estes fundamentos aparecem na área de software, com o surgimento dos métodos ágeis como Scrum e XP, onde usam equipes pequenas e multidisciplinares e auto-organizadas.


Para Trahair (1998, apud MOTTA e VASCONCELOS, 2002), a escola sociotécnica tem em seu cerne a quebra com os métodos tradicionais da administração e traz à tona as seguintes idéias:


• O trabalho é um sistema formado por diferentes partes que devem ser integradas, não pode ser visto somente como um conjunto de atividades individuais e de rotina;
• O grupo organizacional deve ser o principal objeto de análise e não o indivíduo;
• A imposição de regras e o excesso de controle não são eficientes e provocam reações do grupo, deve-se esperar que o próprio grupo organize seu trabalho e se ajuste informalmente;
• As mudanças no sistema de trabalho devem ser feitas nas funções e tarefas e não nos indivíduos;
• Os indivíduos completam as máquinas e não podem ser comparados a elas.
• Com autonomia, os indivíduos tendem a sentir-se mais à vontade para mudar o comportamento e se adequar às mudanças da organização;
• A diversidade cultural e a ambigüidade facilitam as mudanças, a padronização excessiva, ao contrário, dificulta.
• A participação dos empregados no redesenho das tarefas eleva o seu comprometimento com o trabalho.


quinta-feira, 4 de junho de 2009

A História da administração e os métodos Ageis

Este artigo objetiva apresentar a diferença entre os paradigmas dos métodos tradicionais e o Ágil e/ou Lean, enfocando a formação dos grupos de trabalhos organizados para este fim.

No mundo de desenvolvimento de software, as mudanças vêm ocorrendo de maneira cada vez mais abrupta e rápida, exigindo das nós adaptação e inovações sejam em sua estruturas, produtos, processos ou em sua força de trabalho.

Para Mintzberg (1995), inovar quer dizer rebelar-se contra os padrões estabelecidos. Dessa forma, a organização inovativa não pode basear-se em qualquer forma de padronizar a coordenação, ou seja, deve evitar todas as formas induzidas pela estrutura burocrática, especialmente a divisão de trabalho, a diferenciação das unidades, os comportamentos formalizados, a ênfase nos sistemas de planejamento e de controle, devendo permanecer flexível.

É significativa a evolução do conhecimento no que se refere a administração e organização do trabalho, considerando as idéias dos pioneiros Taylor e Fayol até as teorias mais modernas e práticas atuais das organizações. No que diz respeito a desenvolvimento de software, os métodos tradicionais, diga-se de passagem,os ensinados nas faculdadsa estão mais de uma década atrasada.

A dinâmica atual exige que as empresas ajustem seus modelos a fim de obter maior eficácia nas suas operações e, conseqüentemente, maiores ganhos aos seus stakeholders. Este trabalho exemplifica como as organizações podem romper paradigmas, flexibilizando suas estruturas com metodologias Ágeis para atender grandes propósitos.

Como será visto adiante, a evolução deste conceito coincide com a evolução das teorias das organizações, modificando os paradigmas da individualização do trabalho e da especialização dos operários numa determinada etapa do processo produtivo.

Os princípios da administração científica, ditados por Taylor no início do século XX, têm como premissas o trabalho individualizado, a produção em massa e a recompensa por remuneração. Taylor tinha conhecimento, adquirido com a experiência de quem havia trabalhado no chão de fábrica, de que os operários se organizavam para definir o ritmo da produção, considerando que quanto maior fosse a produção individual, menor seria o número de postos de trabalho.

Por esta razão, o trabalho em grupo nunca foi recomendado por ele, pois acreditava que desta forma, o melhor trabalhador, paulatinamente, diminuiria seu rendimento até o nível dos mais ineficientes (TAYLOR, 1987). As idéias apregoadas por Taylor foram reforçadas pela aplicação prática das técnicas da administração científica por Henry Ford, ao implantar a linha de montagem para produção de automóveis (MAXIMINIANO, 2004).

Segundo Womack et al.(1992), a produção em massa em sua forma final amadurecida, evoluída a partir das práticas de fabricação de Ford, das técnicas de marketing e gerência de Sloan e acrescida do novo papel do movimento sindical no controle das definições e conteúdo das tarefas, atingiu seu apogeu na década de 50. Como características deste novo sistema de produção baseado na divisão do trabalho, tem-se:
  • o ritmo de produção, normalmente, era ditado pela linha de produção;
  • supervisão com foco de “fiscalizador”;
  • mão-de-obra sem a visão total do produto, especializada em poucas tarefas e operações, o que possibilitava treinamentos muitos simples e rápidos;
  • tecnologia dedicada e muito pouco flexível para o caso de mudança dos produtos;
  • garantia da qualidade era feita na inspeção final, por especialistas da qualidade;
  • para garantir o funcionamento de todo o sistema, a mão-de-obra indireta era elevada;
  • o baixo custo era viabilizado pela “economia de escala”;
  • os volumes de produção eram elevados e baseados em grandes lotes de produto para garantir a intercambiabilidade de artefatos a baixo custo;
  • não havia o incentivo à participação dos operários no melhoramento do processo;

Na engenharia de software tradicional, esses paradigmas de individualização do trabalho pode ser dividido entre gerente de projeto, analita de sistemas, analista de negócio, arquiteto de software, programadores, testadores, projetistas, o pessoal de suporte, entres outros... onde reaparecem asidéia de departamentalização e especialização de funções, já defendidas por Adam Smith em meados de 1776. No que se refere a função administrativa, Fayol, propôs 14 princípios para a administração das empresas, entre os quais aqui cabem ser destacados: a divisão do trabalho, a definição de autoridade e responsabilidade e a unidade de comando.

Até então as escolas da administração eram essencialmente enfocadas na máxima produção, no aperfeiçoamento dos sistemas de trabalho, mas a partir de 1930 alguns pensadores chamaram a atenção para os fatores humanos que estavam sendo desconsiderados, movimento que passou a ser conhecido como Escola de Relações Humanas no Trabalho. A origem desta Escola é atribuída aos estudos e experiências realizadas, a partir de 1927, em uma fábrica de equipamentos telefônicos de Hawthorne, cujo objetivo era relacionar a produtividade com as condições físicas do ambiente de trabalho, o que embora não tenha sido confirmado, evidenciou que a produtividade era influenciada por padrões e comportamentos informais ditados pelo grupo de trabalho (MOTTA e VASCONCELOS, 2002; MARX, 1997).

É incontestável a contribuição desta escola para a evolução dos estudos acerca do comportamento organizacional, pois despertou o interesse para os aspectos sociais presentes nas organizações. Como conseqüência, surge a Escola Sociotécnica, “desenvolvendo o conceito de que o trabalho por grupos não é nem um sistema técnico nem um sistema social, mas um sistema sociotécnico” (PUGH e HICKSON, 2004, p.175).

Como uma alternativa à distância entre Administração Científica e a Escola de Relações Humanas, apresenta-se a Escola Sociotécnica (MARX, 1997), originada por estudos no Instituto Tavistock em Londres, os quais analisaram os efeitos da mecanização nas minas de carvão britânicas. Eric Trist, responsável pelos estudos, concluiu que a introdução da tecnologia provocou conseqüências sociais e psicológicas para a empresa e para o trabalhador nela inserido (PUGH & HICKSON, 2004).

De acordo com Motta e Vasconcelos (2002), Trist permitiu a identificação de dois subsistemas da organização: o técnico, relativo às tarefas, aos equipamentos, implantações físicas e o subsistema social, referente às relações sociais dos executantes das tarefas.

Para Trahair (1998, apud MOTTA e VASCONCELOS, 2002), a escola sociotécnica tem em seu cerne as seguintes idéias:

• O trabalho é um sistema formado por diferentes partes que devem ser integradas, não pode ser visto somente como um conjunto de atividades individuais e de rotina;
• O grupo organizacional deve ser o principal objeto de análise e não o indivíduo;
• A imposição de regras e o excesso de controle não são eficientes e provocam reações do grupo, deve-se esperar que o próprio grupo organize seu trabalho e se ajuste informalmente;
• As mudanças no sistema de trabalho devem ser feitas nas funções e tarefas e não nos indivíduos;
• Os indivíduos completam as máquinas e não podem ser comparados a elas.
• Com autonomia, os indivíduos tendem a sentir-se mais à vontade para mudar o comportamento e se adequar às mudanças da organização;
• A diversidade cultural e a ambigüidade facilitam as mudanças, a padronização excessiva, ao contrário, dificulta.
• A participação dos empregados no redesenho das tarefas eleva o seu comprometimento com o trabalho.


A partir destas novas visões, o trabalho em grupo passa a ser bem aceito e surgem também os grupos semi-autonomos, que de acordo com Herbst, (1974 apud MARX, 1997) é reconhecido como um grupo que se torna plenamente responsável pela produção e que não tem atribuições definidas pela gerência, mas se auto-organiza e divide as tarefas entre si, cabendo à liderança a intermediação desse grupo com o meio externo. Veja que, estes fundamentos aparecem na área de software, com o surgimento dos métodos ágeis como Scrum e XP, onde usam equipes pequenas, multidisciplinares e auto-organizadas.

Segundo Hillesheim, (1988) grupos semi-autônomos são agrupamentos de empregados articulados entre si, por meio de representantes, responsáveis por um conjunto de tarefas interdependentes voltados a um produto final identificável e significativo. No grupo semi-autônomo há uma mudança radical à medida que os trabalhadores são agrupados, alternando-se sua relação individualizada com seu trabalho. É freqüente e intensa a interação social, uma vez que o trabalho conjunto não pode prescindir de relações sociais constantes.
Para Rodrigues (1999), equipe é um grupo de trabalho amadurecido, temporário ou não, que tem identidade própria, metas e objetivos específicos e definidos, possui alto grau de conformidade, apoio e coesão entre seus membros e recebe responsabilidades específicas na organização.

Shein (1982, p.114) diz que grupo “é um conjunto de pessoas que interagem umas com as outras, psicologicamente conscientes umas das outras e se percebem como um grupo”. Desde o início dos estudos sobre os grupos de trabalho, o grande objetivo era descobrir as variáveis que justificassem a maior ou menor produtividade e eficiência de um grupo e como fazer para que o todo fosse maior do que as partes que o compõem. No meio organizacional, os grupos podem ser divididos em formais e informais. Os formais são os criados pelos dirigentes e que podem ser divididos em permanentes ou temporários. Esses últimos têm sido formados freqüentemente nas organizações produtivas, visando a enfrentar as rápidas e constantes mudanças de contextos e como unidade de maior flexibilidade e eficácia para solução de novos problemas, para os quais não existe uma solução padrão. A importância dos grupos informais para a eficácia e produtividade do grupo é imensa e o saudável desenvolvimento dos grupos informais está relacionado com o fator de sucesso de um grupo ou organização. Não seria possível atingir as metas organizacionais da qualidade sem a energia positiva proveniente dos grupos informais e a não observância da organização em relação a essa energia, tem sido responsável pelo insucesso de algumas tentativas de formação de grupos de trabalhos eficazes. A emoção e o conflito no interior do grupo são aspectos importantes quando canalizadas no mesmo sentido dos objetivos do grupo. As origens e causas das situações conflitantes são diversas, onde as posições antagônicas entre os membros de um grupo são os aspectos mais relevantes e constituem a base de desenvolvimento, crescimento e aprendizagem grupal. Através do gerenciamento, encontra-se a solução dos conflitos, canalizando sua energia para o objetivo grupal ou organizacional e, para o aproveitamento eficaz e saudável dessa energia oriunda das situações conflituosas, é necessário criar no grupo ou na organização, uma filosofia abrangente e normas claras e flexíveis, que possibilitem a discordância entre os membros de um grupo (RODRIGUES, 1999).

Como definido por Trahair, o grupo organizacional deve ser o principal objeto de análise e não o indivíduo. Nas metodologias tradicionais como por exemplo o PMBOK ou RUP (dependendo de quem instancía), o indivíduo normalmente é avaliado de acordo com o tempo estimado para tarefa. Logo surge a pergunta, o que esta sendo avaliado, a estimativa ou a pessoa. Isso piora a medida que elas embutim em sua estimativas; "segurança". Existe uma tendência natural das pessoas de passarem estimativas de tempo extremamente superestimadas, segundo Goldratt (1998) “há três mecanismos diferentes que são usados para se embutir proteção nas estimativas de tempo de quase toda a etapa do projeto:

1) As estimativas de tempo são baseadas em uma experiência pessimista;
2) Quanto maior o número de níveis gerenciais, maior o tempo total das estimativas, porque cada nível adiciona sua própria segurança;
3) As pessoas que estimam os tempos também protegem suas estimativas de cortes”.

Desta forma os tempos estimados, e geralmente utilizados para cada etapa de um projeto, são muito maiores que o valor médio esperado. Se multiplicarmos isto por todas as tarefas do diagrama de rede, teremos que a segurança constitui a maior parte do tempo estimado para um projeto e conseqüentemente gera um aumento desnecessário do tempo para realização do mesmo. Apesar de toda segurança embutida nos projetos, por que então ainda existem atrasos? São várias as causas, dentre elas:

• Síndrome do Estudante: Esse se refere ao comportamento de estudantes que têm a notícia sobre um trabalho que tem que ser entregue no final do semestre, mas esperam até a véspera para começar a fazê-lo.
• Lei de Parkinson: O trabalho se expande para preencher o tempo disponível. Uma tarefa, mesmo que terminada antes do tempo, tende a perder o tempo disponível ou até mesmo atrasar, pois o recurso que está alocado nesta atividade gasta todo o tempo que resta para “terminar de completá-la”.
• Multitarefa: por exemplo, um projeto é composto por 3 atividades, de 3 dias de duração cada, e com um mesmo recurso associado. Se as atividades forem realizadas em seqüência, o projeto durará 9 dias. Se forem realizadas no formato multitarefa, o projeto sofreria um atraso de, no mínimo, o dobro do necessário. Na prática, considerando o tempo necessário de reposicionamento do mesmo recurso entre cada tarefa, esse tempo final poderia ficar ainda pior.

Nos métodos Ágeis este mecanismo de cobrança é totalmente diferente.
http://blog.aspercom.com.br/2009/05/08/reuniao-diaria-cobranca:

"O comprometimento da equipe é maior com a própria equipe do que com os níveis hierárquicos superiores. Quando você está falando o que você fez para a própria equipe você sabe que eles estão no mesmo barco que você. Não há razões para constrangimentos, dissimulações e conflitos. É muito fácil enganar um gerente de projeto que passa com um Gantt Chart perguntando “- Já terminou a tarefa? Quantos porcento ainda falta?”. Agora, não é tão fácil assim enganar os membros da própria equipe… Eles passaram o dia todo com você."
(Rodrigo Yoshima)

Existe uma preocupação constante com o desempenho das equipes nas organizações. Para Scholtes (1992), a eficácia das equipes constitui apenas um dos aspectos dos processos da qualidade, sendo necessário ter conscientização do papel e limitações das equipes, bem como capacitá-las em técnicas de conveniência e sinergia de grupo.

Mintzberg (1995) criou o conceito da Adhocracia, configuração organizacional flexível e complexa capaz de unir peritos tirados de diferentes especialidades em equipes de projetos adhoc, ou seja, uma estrutura grandemente orgânica, com pouca formalização de comportamento, com grande especialização horizontal do trabalho baseada no treinamento formal, com tendências em agrupar especialistas em unidades funcionais visando a administração interna, desdobrando-se em pequenas equipes de projeto. Este tema merece ser melhor detalhado, dada a sua relação com o caso em tela.

Segundo Mintzberg (1995), para solucionar problemas complexos e mal estruturados, nenhuma outra estrutura organizacional é mais adequada que a Adhocracia, pois ela é idealmente adequada para o tipo de projeto único, não sendo competente para executar coisas comuns, além de ser uma produtora por cliente, incapaz de padronizar, a fim de se tornar eficiente. Sua deficiência está no alto custo da comunicação, uma vez que as pessoas conversam muito nessas estruturas para integrarem seu conhecimento para desenvolver novas idéias, demandando muito tempo. Nessa estrutura, todos tomam parte na ação, onde primeiramente, os gerentes devem ser consultados e, em seguida, todos os especialistas, cujo ponto de vista deve ser levado em consideração na decisão .

Dessa forma, o alto custo decorrente da obtenção de uma decisão é parcialmente recuperado na sua execução, se comparada à estrutura burocrática mecanizada, onde é encontrada a resistência dos operadores pelo fato de não terem participado nas decisões. Na Adhocracia ocorre o desbalanceamento das cargas de trabalho, pois é quase impossível manter o pessoal, de alto custo, de uma estrutura de projeto, ocupado em um esforço constante.

De acordo com Mintzberg (1995, p. 17), na Adhocracia “as organizações são estruturadas para aprender e dirigir sistemas de fluxos e determinar os inter-relacionamentos das diferentes partes. Tais fluxos e inter-relacionamentos dificilmente são de formato linear, com os elementos seguindo ordenadamente um depois do outro”. Entre as formas de estrutura organizacional, é a que demonstra a menor aderência aos princípios da administração clássica, principalmente no que se refere à unidade de comando.

• Quando a organização tem a necessidade de inovar por razão de intensa competição por produto ou uma tecnologia dinâmica e o seu núcleo operacional é uma burocracia mecanizada, podendo ser instituído como uma organização isolada e o componente administrativo da organização ser estruturado organicamente para a inovação;
• Quando o núcleo operacional pode ser totalmente abolido, podendo ser contratado de outras organizações, permitindo que a organização fique livre para se concentrar no trabalho de desenvolvimento;
• Quando o núcleo operacional é automatizado e capaz de operar por si mesmo. Em razão de não mais necessitar atender a assuntos de operação rotineira, pode-se estruturar preocupada só com a mudança e a inovação, com projetos para trazer novos instrumentos para a operação contínua.

Especialmente as pessoas criativas, não gostam tanto da rigidez estrutural como da concentração de poder, levando-as à Adhocracia, que é a única estrutura organizacional orgânica e descentralizada, considerada por elas um ótimo local para trabalhar, pois acreditam ser o mais democrático e menos burocrático dos ambientes. No entanto, as condições da organização é que devem demandar por esse tipo de estrutura, onde o conflito e a agressividade são elementos necessários, cabendo aos gerentes canalizá-los para fins produtivos. E mesmo os membros dedicados a Adhocracia, periodicamente mostram pouca tolerância pela sua fluidez, confusão e ambigüidade, almejando por mais definição e estrutura (Mintzberg, 1995), isto remete para a idéia de que não há um tipo ideal de estrutura para todas as organizações, o que reforça a essência da teoria da contingência comentada a seguir.


Conforme Donaldson (1999), a teoria da contingência estabelece que não existe uma estrutura organizacional única na qual seja altamente efetiva para todas as organizações e que a otimização da estrutura varia de acordo com determinados fatores contingenciais, como: a estratégia da organização, o tamanho, a tecnologia e a incerteza com relação às tarefas, além da inovação, considerada um fator contingencial subjacente, que influencia diretamente no nível de incerteza das tarefas. Dessa forma, uma organização ótima precisa adequar a sua estrutura a seus fatores contingenciais e ao ambiente no qual está inserida, uma vez que este também exerce influência significativa sobre a organização.


Para Lawrence e Lorsch (2004), as organizações de melhor performance são as que conseguem estabelecer um equilíbrio dinâmico entre diferenciação e integração, adaptando o equilíbrio às condições ambientais, onde a diferenciação é o processo pelo qual uma organização aloca os seus recursos para a realização das tarefas, definindo as relações de autoridade e estabelecendo as tarefas que permitem atingir os objetivos, ou seja, o processo de estabelecer e controlar a divisão de trabalho numa organização. Já a integração é o processo de estabelecer e controlar as diversas tarefas, funções e divisões de forma a trabalhar com sinergia e com objetivos em comum. Para estes pesquisadores determinadas áreas de uma organização, como por exemplo, a de produção, exigem estruturas mais formais, enquanto outras, especialmente as que lidam com horizontes de longo prazo como as áreas de desenvolvimento, necessitam de configurações informais, menos rígidas, favorecendo a criação.

A teoria da contingência, de acordo com Bertero (1999), é vista como sendo uma desistência da construção de one best way da prática administrativa diante da impossibilidade de construir uma explicação única para a estrutura organizacional. É vista como um sinal de maturidade, visualizando a teoria como modelo de “ciência normal”, capaz de flexibilizar-se pela absorção de outras perspectivas contingencializadoras e renunciar à universalização.