Qual a diferença entre Equipe e Time?

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Dentro do domínio da gestão de projetos, é muito comum a utilização dos termos “time” e “equipe”. Alguns, quando querem demonstrar que suas equipes são altamente coesas e costumam atingir os objetivos do projeto, escolhem o termo “time”. Será que o termo “equipe” significa um conjunto de profissionais incompetentes que não costumam atingir seus objetivos? Claro que não! Qual será a diferença entre os termos “time” e “equipe”?

O Wikcionário (http://pt.wiktionary.org) descreve “time” como um grupo de pessoas envolvidas em atividades semelhantes e descreve “equipe” como um conjunto de pessoas encarregadas de qualquer tarefa em comum. A diferença parece existir, mas não ficou clara.

A Wikipédia (http://pt.wikipedia.org), na ocasião em que consultei, descreve “equipe” como um grupo de pessoas com habilidades complementares que trabalham juntas com o fim de atingir um propósito comum. Faz ainda uma associação a uma agremiação esportiva, tal como um time de futebol.

A minha interpretação é que o termo “time” leva a entender que é um tipo especial de equipe, porque reúne pessoas com habilidades complementares. Por exemplo, um time de futebol é formado por onze jogadores onde cada um desempenha um papel diferente de tal forma que um complementa o papel do outro.

Com isso, chego à conclusão que o termo “equipe” tem um conceito mais genérico, ou seja, reúne pessoas que trabalham para atingir um determinado objetivo. Um time de futebol, neste sentido, pode ser considerado uma equipe, porque todos têm o mesmo objetivo, o qual é ganhar o jogo. Em contrapartida, podemos também ter uma equipe onde cada membro faz exatamente a mesma coisa, ou seja, possuem o mesmo papel.

No contexto da Engenharia de Software, o termo “time” poderia ser aplicado para uma equipe onde cada membro possui um papel diferente (complementar), tais como gerente do projeto, arquiteto de software, analista de negócio, projetista, programador (popularmente chamado de desenvolvedor), testador, etc. Como se vê, temos um grupo de pessoas com papeis diferentes e complementares. Creio que podemos chamar esse grupo de “time”.

Entretanto, se tivermos um grupo de programadores fazendo exatamente a mesma coisa, ou seja, programando, entendo que temos aí, uma equipe de programadores. É possível que alguém possa argumentar que não, ou seja, temos um time de programadores porque cada um está fazendo um programa (método de uma classe, stored procedure, etc.) diferente. Insisto ainda dizer que se trata de uma equipe, porque cada programador com seu respectivo programa em desenvolvimento, corresponde à uma instância de um mesmo papel.

Este é um excelente tema para uma discussão acadêmica. Para que serve? Talvez para nada... mas poderá servir como um exercício mental para desenvolvermos nossa capacidade de descrever corretamente elementos abstratos que nos cerca no nosso dia-a-dia, muito útil para Analistas de Negócio e Analistas de Requisitos.

Convido a todos a fazerem seus comentários sobre este tema. Quem sabe poderemos chegar a uma descrição consistente. Se chagarmos, poderemos colaborar com o Wikcionário e com a Wikipédia.

Bibliografia sobre BPM, Requisitos, UML, OOAD, Metodologias, etc

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Este é o primeiro post que estou disponibilizando sobre o tema “Bibliografia”. Meu objetivo é apresentar o maior número possível de referências bibliográficas para ajudar aos profissionais em seus estudos como autodidata, bem como aos alunos de graduação e pós-graduação (lato e stricto sensu).

Posteriormente, em post futuros, irei comentar o conteúdo de cada uma dessas referências para facilitar a tão difícil tarefa de pesquisa bibliográfica necessária para a elaboração TCC (Trabalho de Conclusão de Cursos), dissertação de mestrado e doutorado.

Convido aos leitores deste blog a colaborarem conosco enviando-nos suas referências bibliográficas. O nome do colaborador irá constar junto às referências cedidas.

Segue abaixo a primeira versão das referências bibliográficas:

Bibliografia sobre processos de software (metodologias).
• KRUCHTEN, Philippe; Introdução ao RUP Rational Unified Process; Editora Ciência Moderna.
• JACOBSON, I.; BOOCH, G.; RUNBAUGH, J.; The Unified Software Development Process; Addison Wesley.

Bibliografia sobre UML (Unified Modeling Language).
• Fowler, M.; “UML Essencial – Um breve guia para a linguagem padrão de modelagem de objetos”; Bookman; 2000.
• Booch, G.; Rumbaugh J.; Jacobson I.; “UML Guia do Usuário”; Ed. Campus; 2006.
• OMG; Unified Modeling Language: Superstructure; Versão 2.1; ptc/2006-04-02.
• Larman, Craig; Utilizando UML e Padrões; 2ª Edição; Bookman, 2002.
• Pender, Tom; UML a Bíblia; Editora Campus; 2004.
• Borges, C.C.P.; Sistema de Controle de Eventos Utilizando Metodologia ICONIX; Dissertação de Mestrado; UFJP; 2005.

Bibliografia sobre Gestão de Requisitos.
• Bittner, K; Spence, I; Use Case Modeling; Addison Wesley;
• Cockburn, Alistair; Escrevendo Casos de Uso Eficazes; Bookman; 2007.
• LEFFINGWELL, D; WIDRIG, D.; Managing Software Requirements – A Unified Process; Addison Wesley.

Bibliografia sobre Análise-Design Orientado a Objetos
• Jones, M.P; Fundamentos do Desenho Orientado a Objetos com UML; Makron Books; 2001.
• Fowler, M.; “Analysis Patterns: Reusable Object Models, MA.; Addison-Wesley; 1996.

Bibliografia sobre Engenharia de Software.
• SWEBOK – Software Engineering Body of Knowledge; Versão 2004; IEEE.
• OMG – Object Management Group; UML Superstructure Specification, v2.1; ptc/2006-04-02; April/2006.

Uso de Templates

Nosso blog está mudando de endereço. Acesse www.wm2info.com.br.

Template é um formulário que é usado para facilitar a criação padronizada de um documento ou artefato. Deveria ser um instrumento de trabalho que levasse o analista a realizar o seu trabalho com sucesso.

Tenho percebido que os templates, algumas vezes, se transformam em um problema para o sucesso de um projeto. Vou explicar relatando um episódio que ocorreu comigo, na ocasião em que eu estava aplicando um processo de coaching em um projeto.

Um analista estava tendo alguns problemas na descrição de um caso de uso, porque era grande e complexo, com muitos fluxos alternativos, fluxos de exceção e regras de negócio. Percebia claramente que o analista não conseguia definir corretamente os fluxos alternativos e de exceção. Para resolver o problema sugeri que ele elaborasse um diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso e, a partir desta visão pudesse definir corretamente os fluxos de eventos.

Surpreendi-me quando ele disse-me que não iria fazer o diagrama porque não era obrigatório e também não estava elencado como um produto contratado. Argumentei que embora não fosse um entregável, era importante para que ele produzisse uma descrição do caso de uso com precisão e qualidade.

Posteriormente o gerente entrou na discussão alegando que a elaboração deste diagrama não estava previsto no cronograma e que a sua elaboração iria consumir um tempo que não tinha sido planejado e pediu-me, portanto, que eu não insistisse sobre o diagrama de atividades.

A conclusão dessa história é que o caso de uso foi descrito de uma forma altamente imprecisa, incompleta, não retratando o comportamento esperado. O tempo que aquele analista gastou para descrever aquele caso de uso foi, no mínimo, três vezes maior do que ele gastaria se estivesse elaborado o tão popular diagrama de atividades.

Para concluir a história, quando a equipe de design foi realizar aquele caso de uso, criando o modelo de design com o diagrama de classes e diagrama de sequência, não conseguiram concluir o trabalho, porque o caso de uso não estava claro, era impreciso e muitas coisas não faziam sentido. Com isso, aquele analista teve que fazer vários ciclos de alterações na descrição até que tivesse totalmente pronto para atender aos rigores da equipe de desenvolvimento.

É interessante notar que além do tempo excessivo que o analista gastou na descrição inicial do caso de uso, gastou ainda muito mais tempo para fazer as correções exigidas pelos desenvolvedores, além do tempo que a equipe de desenvolvimento gastou para entender e sugerir correções para o analista.

Lembra-se do gerente do projeto? Aquele que disse que não havia tempo para gastar com o diagrama de atividades? Coitado, passa maior parte do tempo atualizando cronogramas e levando pancada do cliente, que reclama que ele não consegue cumprir o planejamento inicial.

Porque tudo isso aconteceu? Porque tanto o gerente do projeto quanto o analista de negócio/requisitos, trabalham orientados à template. Para eles, o importante é preencher os campos do template. Esquecem-se de que os diagramas da UML poderiam ser de grande ajuda para se obter o entendimento do problema e para a definição adequada de uma solução. Esses diagramas possuem a excelente propriedade de oferecer múltiplas visões da solução idealizada. Essas visões irão colaborar para uma descrição clara, precisa, consistente e não ambígua dos casos de uso.

Não tenham medo de gastar tempo na elaboração do diagrama de atividades para obter uma visão panorâmica do comportamento do caso de uso. Certamente você irá ganhar tempo no cômputo geral do projeto. Além do que você irá evitar perda de tempo da equipe de design e de implementação.

Template é um excelente instrumento de trabalho, mas antes de preenchê-lo, pense, mas pense usando os excelentes diagramas da UML.