Caixas

maio 13, 2008

Um trecho do livro Você está louco! do Ricardo Semler, um cara que questiona tudo. Neste trecho ele questiona o sistema de ensino e a noção de sucesso em uma teoria curiosa mas bem real, a qual ele chama teoria das caixinhas:

No mundo adulto, a idéia é deixar a vida pessoal para trás, sair de uma caixinha (apartamento) pela manhã, entrar em outra, sobre rodas (ônibus, metrô ou carro) e chegar em outra maior (escritórios ou fábricas sem vista para fora), para ficar o dia inteiro, e voltar via caixa-sobre-rodas para a caixa-mãe. Lá, é sentar na frente da caixinha-com-tela ou daquela caixa-com-Internet, depois cair desacordado por sobre uma caixa-com-colchão. No dia seguinte, transitar novamente entre caixinhas. Que vida!

Na infância, a mãe deixa a criança na porta da escola, muitas vezes contra a vontade da bichinha, para ser “cuidada” e educada por terceiros. Uma caixinha da qual ela não pode sair, na qual ela é empilhada com outras 20 crianças, sem poder sair para o pátio (outra caixinha, aliás, da qual ela também não pode sair).

Se isso for treinamento para uma vida insossa em caixinhas claustrofóbicas, é realmente um sistema exemplar. Se for para ensinar à criança que a vida é cruel, que nunca é possível fazer o que se quer, que mais tarde tudo será assim – cinzento, duro e repetitivo -, então o sistema educacional é um sucesso. Prepara, de fato, a criança para o miserável mercado de trabalho que os pais míopes acham que será igual daqui a 15 anos, quando suas crianças virarem jovens adultos prontos para brigar, competir, atropelar e acotovelar, para serem capazes de comprar caixinhas maiores para morar, caixinhas mais rápidas para dirigir e caixinhas de canto no escritório para trabalhar. Onde pessoas dentro de caixinhas de organograma mandam em caixinhas de cronogramas. Ora…

O que está no âmago do que os pais procuram na educação? Afinal, as crianças são papéis em branco, prontas como esponjas para serem inculcadas com conhecimento e práticas sociais? São matéria-prima para o difuso rei-pagão, o mercado de trabalho? Devem ser sacrificadas no altar do emprego, para então serem declaradas sucesso ou fracasso, dependendo de quanto subirem na hierarquia das caixinhas?

As empresas da era industrial se utilizam bastante das pequenas caixas. Com seus complexos e completos processos, tratam as pessoas como executores de tarefas definidas em caixinhas.

Anúncios

Construção é projeto

abril 29, 2008

Escrevi uma tradução de um fragmento do livro “Software Project Secrets: Why Software Projects Fail”. Este trecho retrata bem a má interpretação que é feita do processo de desenvolvimento de software.

Construção é projeto

A construção de estradas consiste em uma sequência de fases bem definidas. O primeiro passo é planejar e projetar, o que resulta em um conjunto de planos e projetos (blueprints) que podem ser assinados. Uma vez que essas tarefas sejam concluídas a construção pode começar. A fase de construção consiste principalmente de tarefas bem definidas e repetitivas que podem ser executadas por empregados menos qualificados.
Ao contrário, o desenvolvimento de software é um processo de pesquisa, portanto em nenhum momento pode-se ter planos definitivos. Quanto mais definitivo tenta-se fazer os planos, mais falhos eles serão, e mais trabalho se terá ao revisá-los para que cumpram as mudanças de circunstâncias. Como a forma do sistema fica incrementalmente mais clara durante o curso do projeto, seu projeto (design) deve ser revisado constantemente. Reprojetar (redesign) a solução completamente de tempos em tempos pode ser custoso e desnecessário, portanto devemos pensar o projeto como um processo de design constante.
Sabemos que o trabalho repetitivo no desenvolvimento de software é rapidamente automatizado. Não existe nenhuma tarefa repetitiva a definir. Mas se as tarefas não são repetitivas, definí-las exaustivamente se torna um processo muito custoso em tempo. Ganha-se muito pouco definindo as tarefas dessa maneira. Software é abstrato, portanto definir as tarefas da construção completamente é equivalente a realizar o trabalho, pois existem ferrametas automatizadas que conseguem transformar estas definições em código.
Se as tarefas não podem ser bem definidas, então não podemos separar claramente as fases de design (projeto) e construção. Aliás, não existe fase de construção; o que existe é design (projeto) em escalas cada vez menores (níveis cada vez mais baixos). Isso significa que não podemos facilmente categorizar as pessoas nos papéis de arquitetos, projetistas (designers), programadores ou analistas. Estes papéis se sobrepoem. Todos os desenvolvedores têm o mesmo tipo de tarefas a fazer, apesar de uns terem mais responsabilidades que outros.
Quando um desenvolvedor cria uma nova funcionalidade num pedaço de software, a sua tarefa é simplesmente responder a seguinte pergunta “Essa funcionalidade irá funcionar exatamente como?”. Ele adiciona um conjunto de instruções ao código fonte que definem cada detalhe de como a funcionalidade funcionará. Porém, cada detalhe é uma decisão de projeto. Por exemplo, um fragmento de texto pode ser armazenado em um objeto imutável para uma maior eficiência, ou em um objeto mutável para maior flexibilidade. A escolha de uma dessas opções depende de como o texto será utilizado. É uma decisão bem significante.
Programar é mais do que apenas escrever código. Cada passo requer que o desenvolvedor analise uma parte do problema e projete uma parte da solução.

NOTA: Diferentemente de outros produtos, software não é construído, é projetado até a sua existência.

Acho que esse é um dos pontos em que as metodologias ágeis acertam e o RUP e os processos tradicionais falham. É um erro absurdo tratar a construção como uma tarefa repetitiva (tradução de diagramas para código fonte) que pode ser executada por empregados mais baratos (codificadores, programadores).
Como escutei lá no FISL, o movimento ágil é legal e funciona porque foi feito por programador para programador. É coisa de nerd mesmo!


Processos e confiança

abril 11, 2008

O processo de desenvolvimento de sw reflete totalmente a maneira como a empresa é administrada e como esta se relaciona com as pessoas.
Achei um artigo que compara alguns aspectos dos processos baseados no CMMI com os processos ágeis. Achei muito interessante a discussão sobre confiança.

The heart of the conversation was on the perception that if a model forces us to write something down then we are not trusted (the more we write stuff down, the less we trust one another).

Me parece ser bem adequada a colocação do autor, uma vez que um dos objetivos de toda a documentação que o CMMI impõe é a independência da empresa em relação às pessoas. Esse objetivo reflete de maneira muito clara a falta de confiança nas pessoas.


Casos de uso

abril 8, 2008

Do livro “UML Destilada” do barbudo Martin Fowler:

Diagramas de caso de uso são índices…

The best way to think of a use case diagram is that it’s a graphical table of contents for the use case set.

Essa é a melhor:

The UML includes other relationships between use cases beyond the simple includes, such as «extend». I strongly suggest that you ignore them. I’ve seen too many situations in which teams can get terribly hung up on when to use different use case relationships, and such energy is wasted. Instead, concentrate on the textual description of a use case; that’s where the real value of the technique lies.

Eu mesmo já perdi muito tempo pensando se eu deveria usar include ou extend, o pior é quando perde-se tempo discutindo qual relacionamento é melhor para uma situação X!

Outra:

You don’t have to write all the detail down; verbal communication is often very effective, particularly within an iterative cycle in which needs are quickly met by running code.

É bom lembrar disso quando for preencher templates de casos de uso. Numa dessas, é mais eficiente resolver na palavra falada.


Rastreabilidade de requisitos, qual é o teu problema?

abril 24, 2007

Já ouvi dizer que o problema que a rastreabilidade de requisitos tenta resolver é: Em uma situação de alteração ou manutenção, é necessário identificar os artefatos (leia-se classes e documentos) relacionados ao requisito que está sofrendo a alteração.

Será que não existe nada mais simples para fazer isso?

Me parece que as seguintes soluções são melhores:

  • Cobrir a aplicação com testes automatizados de unidade, integração e funcional. Dessa forma, o impacto de qualquer alteração já se reflete nos testes. Muito mais confiável do que olhar uma matriz e analisar o impacto.
  • debug da aplicação com um ou mais breakpoints

Mais alguma solução?