Atividade:  Avaliar Organização Atual

Para configurar um processo e criar um caso de desenvolvimento para um projeto específico, é necessário entender o contexto do projeto, ou seja, o estado atual da organização de desenvolvimento de software em termos de pessoas, processos e ferramentas de suporte. Para configurar corretamente o processo, é importante entender áreas de problema e possíveis áreas de melhoria, bem como informações sobre questões externas, como, por exemplo, concorrentes e tendências do mercado. Quando concluir esse passo, você deverá saber:

• O estado atual da organização de desenvolvimento de software
• O tipo de pessoas envolvidas e seu nível de competência, habilidades e motivação
• As ferramentas usadas no momento pela organização
• O atual processo de engenharia de software e como ele é descrito

Os motivos para avaliar o estado atual devem permitir:

• Usar o estado atual como entrada ao configurar o processo.
• Identificar as áreas que precisam de melhorias em primeiro lugar. Não é preciso apresentar o processo inteiro nem todas as ferramentas de uma única vez. É interessante fazê-lo em incrementos, começando com as áreas de maior necessidade e que apresentam maior potencial de melhoria.
• Explicar aos patrocinadores por que você precisa fazer mudanças no processo, nas ferramentas e no pessoal.
• Criar motivação e um entendimento comum entre as pessoas da organização no que se refere a quem será afetado direta e indiretamente pelas mudanças.

Iniciar uma Avaliação

Recomendamos que você inicie a avaliação com um workshop reunindo as pessoas-chave conhecidas no momento. A principal finalidade desse workshop inicial é fazer com que os engenheiros de processo conheçam os envolvidos do projeto para que possam fazer uma lista abrangente dos problemas a partir da perspectiva dos envolvidos. Consulte Orientações de Trabalho: Workshop de Avaliação para obter detalhes sobre como conduzir esse tipo de workshop inicial.

Identificar os Envolvidos

Identifique os envolvidos no esforço para implementação do processo. Identifique os envolvidos que estão fora da organização de desenvolvimento, como, por exemplo:

• Clientes. Quem são os clientes? Quais são as necessidades dos clientes quanto aos produtos em termos de tempo de comercialização, características, proteção, robustez, segurança e complexidade?
• Concorrentes. Quem são os concorrentes? Em quais áreas os concorrentes são fortes? O que você pode aprender com os concorrentes?
• Outros envolvidos. Existem outros envolvidos? Os fornecedores e os parceiros estão envolvidos? Os relacionamentos com eles são difíceis?

Identifique os envolvidos que estão dentro da organização de desenvolvimento, como, por exemplo:

• Membros do projeto
• Gerente de projeto
• Marketing
• Pessoas de outros departamentos de desenvolvimento

Pergunte aos envolvidos ou representantes quais são as expectativas que eles têm em relação à organização de desenvolvimento.

Descrever a Organização Interna

Descreva a organização interna, especificamente os papéis e as equipes atuais. Além disso, considere o relacionamento entre as diferentes partes da organização de desenvolvimento. Por exemplo, qual é o relacionamento entre desenvolvimento e manutenção e entre desenvolvimento e teste?

Identificar Pessoas-chave

Peça às pessoas da organização para identificar as pessoas-chave. Uma pessoa-chave é alguém que tem uma ou várias das seguintes características:

• Conhece a expectativa do público
• Atua como mentor
• É especialista em alguma área
• Opõe-se ao processo de implementação
• É responsável pelo orçamento

• No restante da avaliação, para coletar informações
• Como especialistas, para ajudar a adaptar o processo
• Para trabalhar no projeto piloto e, depois, como mentores

Observação: Fique atento às pessoas que querem discutir processo e metodologia em vez de desenvolver sistemas.

Identificar os Motivos Básicos para as Mudanças

Pergunte aos envolvidos por que eles desejam mudar para um novo processo e novas ferramentas implementando o Rational Unified Process (RUP). Abaixo, algumas respostas típicas e seu efeito sobre a maneira como o processo é implementado:

• "Compramos algumas ferramentas e o RUP veio 'grátis'. Parece uma boa idéia usá-lo."
  Nesse caso, você terá de ser muito cuidadoso ao implementar o processo; implemente apenas pequenas partes do processo para mostrar o andamento.
• "Começamos a usar uma nova tecnologia e precisamos de orientação."
  Nesse caso, introduza somente aquelas partes do processo que oferecem a orientação de que as pessoas precisam para usar essa nova tecnologia.
• "Precisamos de um processo, mas não queremos desenvolvê-lo por nós mesmos. Na verdade, tentamos desenvolver nosso próprio processo, mas fomos dominados pela tarefa. Simplesmente não tínhamos condições de desenvolvê-lo e mantê-lo."
  Nesse caso, seja mais ofensivo na implementação do processo. Essas pessoas desenvolveram e utilizaram o processo anteriormente e, portanto, estão propensas a ter uma visão pragmática do processo e de sua importância.

Identificar Competências

Faça uma lista das áreas de competência relevantes, como aquelas mostradas na seguinte lista:

• Processo
  • Modelagem de negócios
  • Requisitos
  • Design da interface gráfica do usuário
  • Análise e design
  • Implementação
    • Bancos de dados Java, C++, Relacionais
• Ferramentas
  • Rational RequisitePro, Rational Rose etc.
• Domínio de problema
• Tecnologia
  • Sistemas distribuídos etc.
• Habilidades administrativas e organizacionais
• Habilidades de relacionamento interpessoal e comunicação
• Conhecimento organizacional

Para cada uma dessas áreas de competência, avalie o conhecimento, a habilidade e a experiência das pessoas da organização. Isso pode ser feito de diversas maneiras:

• Peça a um ou a vários gerentes para ordenar as competências de pessoas separadamente ou de equipes inteiras.
• Peça aos funcionários que eles mesmos ordenem suas competências em cada área.

Para cada área, avalie a competência das pessoas individualmente. Você pode usar este exemplo de uma escala de uma única competência:

• Especialista. Atua como mentor de outras pessoas.
• Conhecimento prático. Pode trabalhar de modo independente.
• Conhecimento básico. Eventualmente pode precisar de ajuda.
• Novato. Pode não estar familiarizado com o assunto.

Faça um perfil de competência de cada pessoa e compile perfis de competência de equipes inteiras. É importante conhecer o perfil de competência de uma equipe como um todo porque nenhuma pessoa sozinha pode ter todas as competências necessárias.

Avaliar Atitudes

Entreviste as pessoas para entender suas atitudes em relação a mudar para uma nova tecnologia, novas ferramentas e novos processos. Se as pessoas tiverem uma postura negativa ou cética em relação à mudança, é impossível que ela seja bem-sucedida, a menos que você transforme atitudes negativas em positivas.

Consulte a seção "Atitudes" em Conceitos: Discriminantes do Processo para obter sinais típicos de atitudes negativas e entusiasmo exagerado e conhecer métodos de lidar com eles.

Avaliar a Capacidade de Mudança

Analise a capacidade de mudança na organização e entre as pessoas. Quando se analisa os problemas da organização, há uma tendência de se querer corrigir tudo de uma vez, especialmente porque muitos desses problemas ocorrem juntos. Esta armadilha é fatal. As organizações, assim como as pessoas, podem acomodar a mudança apenas dentro de um escopo limitado. Algumas organizações estão mais bem preparadas para mudanças do que outras. Para entender a capacidade organizacional de mudança, entreviste pessoas da organização para conhecer as atitudes e a disposição para mudança.

Analisar a Descrição do Processo de Desenvolvimento

Leia as descrições existentes do processo para entender a profundidade do processo de desenvolvimento em vigor. Para cada disciplina, identifique os tipos de descrição existentes. Por exemplo, descubra se não existem quaisquer descrições e se há exemplos, diretrizes, templates de documento, descrições de atividades e de artefatos e assim por diante.

Dispondo de um bom entendimento do processo existente, você irá:

• Entender a qual tipo de descrição de processo as pessoas da organização estão acostumadas - por exemplo, se elas já tiverem uma descrição extensiva do processo, estarão propensas a adotar o RUP rapidamente; no entanto, se não tiverem nenhuma descrição do processo, você deverá ser muito cauteloso e implementar o RUP em pequenos incrementos.
• Entender quais áreas têm maior urgência de uma nova descrição de processo.
• Entender quais partes da descrição do processo dessas pessoas podem continuar sendo utilizadas. Mesmo que a meta fundamental seja usar todo o RUP, você deverá implementá-lo em incrementos. Isso significa que o projeto continuará a usar uma parte da descrição existente do processo durante um tempo.

Caracterizar o Projeto e o Aplicativo

Descreva as características dos projetos e aplicativos típicos da organização. Considere os projetos finalizados e os que estão em andamento. Colete informações entrevistando pessoas ou equipes inteiras. Consulte Orientações de Trabalho: Entrevistas e Orientações de Trabalho: Brainstorming e Filtro de Idéias para obter mais orientações. Estude os resultados gerados pelos projetos - por exemplo, planos de projeto, artefatos criados pelo projeto, descrições de processos, opiniões sobre o projeto, avaliações do status final e assim por diante.

Obtenha as seguintes características sobre cada projeto e o respectivo produto:

• Dimensão dos esforços para desenvolvimento de software. Qual é a dimensão do produto?
• Grau de inovação. Em uma escala, qual é a posição do produto entre "desenvolvimento a partir do zero" e manutenção?
• Tipo de aplicativo. O aplicativo é de importância fundamental? Existem requisitos que exigem seguir padrões específicos?
• Identifique o tipo de desenvolvimento normalmente realizado pela organização. Por exemplo, se se trata de trabalho mediante contrato, desenvolvimento especulativo, desenvolvimento interno ou estudos prévios. Consulte a seção "Tipo de Desenvolvimento" em Diretrizes: Discriminantes do Processo para obter detalhes.
• Complexidade técnica. Quais são os desafios e problemas técnicos advindos da criação do produto? Por exemplo, o aplicativo é um sistema distribuído, um sistema de segurança vital ou um sistema de alta integridade? Existem sistemas legados que serão reutilizados?

Para entender os fatores e os efeitos que eles terão sobre como o processo deve ser adaptado, consulte Diretrizes: Discriminantes do Processo.

Identificar as Ferramentas de Suporte

Identifique as ferramentas que estão sendo usadas pelos projetos. Identifique as áreas nas quais os membros do projeto carecem de ferramentas de suporte. Consulte Conceito: Ferramentas de Suporte para obter informações.

Identificar Problemas

A melhor maneira de identificar problemas é reunir diversas pessoas-chave para uma sessão de identificação de problemas. Consulte Orientações de Trabalho: Brainstorming e Filtro de Idéias para obter instruções gerais sobre como organizar uma sessão dessa natureza. Observe que existem situações nas quais não faz muito sentido identificar problemas e isso ocorre se as pessoas não dispõem de um modo de trabalho (consulte a seção "Mudança Geral" em Conceitos: Implementação de um Processo em um Projeto para obter mais detalhes). 

Para identificar problemas, faça perguntas como:

• Quais são os problemas dos projetos?
• Algum item está invalidado?
• Os projetos estão rotineiramente atrasados ou acima do orçamento?
• Foi obtida alguma métrica que possa ser analisada?

Não deixe de cobrir todas as áreas do processo de desenvolvimento, incluindo todas as disciplinas, ferramentas de suporte e competências. Considere também os problemas políticos e organizacionais. Consulte a seção "Problemas e Causas Originais" em Diretrizes: Discriminantes do Processo para obter uma lista dos problemas comuns relacionados a processos.

Identifique os efeitos negativos que cada problema tem, ou terá, sobre os projetos se não for eliminado ou reduzido. Conhecer o efeito de um problema ajuda a entender quão importante é eliminá-lo ou reduzi-lo.

Identifique as causas originais de cada problema para entender melhor como eliminar, ou reduzir, o problema e quanto isso custará. Diagramas espinha de peixe podem ajudá-lo a entender esse conceito. Se um problema tiver várias causas originais,  você deverá compará-las umas com as outras; nesse caso, os diagramas de Pareto podem ser bastante úteis.

Classifique os problemas quanto ao efeito que causam. Por exemplo, use uma escala de 1 a 5, onde 5 indica problemas com efeito mais perigoso e 1, problemas inócuos. A principal finalidade é entender a importância relativa dos problemas.

Liste os problemas em uma tabela:

Tirar Conclusões

Analise os resultados das informações coletadas e compile uma lista de áreas e problemas que exigem atenção. Geralmente, as questões a serem abordadas no início se enquadram em uma ou várias das seguintes categorias:

• Principais áreas de problema, nas quais é possível melhorar significativamente o desempenho dos projetos.
• Áreas nas quais é possível gerar lucros a curto prazo e rapidamente mostrar os resultados.
• Áreas nas quais uma melhoria terá grande visibilidade.

Documente as informações coletadas e as conclusões no Artefato: Avaliação da Organização de Desenvolvimento.

Fazer Recomendações

Geralmente, algumas recomendações a serem consideradas no futuro são necessárias como parte da avaliação. A recomendação deve descrever como o projeto de desenvolvimento (ou toda a organização de desenvolvimento) deve avançar para implementar o novo processo e as novas ferramentas. As recomendações podem consistir em esboços de planos de implementação, planos de projeto, casos de desenvolvimento e assim por diante.

Copyright  (c) 1987 - 2001 Rational Software Corporation

Rational Unified Process