Atividade IFC – Inspeção das Funcionalidades junto ao Cliente

Objetivo: Validar as versões iniciais das funcionalidades. Essa atividade procura

identificar possíveis erros e obter maior entendimento das funcionalidades. Ela foi gerada com base na Validação I do PI-XP.

Embasamento: Embora os MA enfatizem a necessidade da presença constante do

cliente junto à equipe de desenvolvimento (MANIFESTO, 2001), esse princípio nem sempre é aplicado dado o custo gerado por manter o funcionário da organização cliente fora de suas atividades produtivas. Isso justifica a proposta dos papéis do cliente sênior e do cliente representativo na organização cliente, ambos utilizados na Validação I do PI-XP.

A existência dos papéis do cliente sênior e o cliente representativo não são definidos nos MA estudados, porém, a existência desses papéis na organização cliente é verificada na maioria das empresas através dos cargos de gerência e subordinados.

O cliente sênior é o elo entre a equipe de desenvolvimento e a organização cliente, responsável pelo sistema em geral, enquanto os clientes representativos são as pessoas que terão maior interação com as funcionalidades específicas do sistema.

Durante o levantamento das funcionalidades em suas versões iniciais, ou seja, no levantamento de requisitos, o cliente sênior, embora tenha o domínio das regras de negócio, ele não conseguirá fornecer todos os detalhes para a implementação das funcionalidades em um único momento. Isso pode ocasionar dúvidas à equipe de desenvolvimento e inconsistências entre essas funcionalidades, aumentando a possibilidade de inconsistências e falhas. Assim, no levantamento das versões iniciais das funcionalidades, podem ser omitidos detalhes fundamentais necessários para o desenvolvimento das funcionalidades.

Mesmo adotando o papel do cliente sênior, em geral, este também não tem disponibilidade total para atender as dúvidas da equipe de desenvolvimento a qualquer momento.

Evidência do embasamento: Os exemplos que são mostrados foram obtidos em duas

empresas, aqui denominadas “A” e “B”, cujo segmento de mercado não é voltado à Tecnologia da Informação. Esses exemplos mostram falhas que podem ocorrer na especificação das funcionalidades, principalmente quando elas são escritas somente por membros da organização cliente.

A empresa “A” atua no segmento de transformação de fibra-de-vidro. Atualmente conta com, aproximadamente, quatrocentos funcionários e um faturamento mensal de seis milhões de reais. Essa empresa utiliza um sistema de gestão que abrange todos os seus departamentos e áreas produtivas. A empresa “B” atua no segmento de distribuição de materiais de construção. É considerada uma empresa de pequeno porte, tendo hoje, aproximadamente, 10 funcionários e não possuindo um sistema de gerenciamento integrado. Embora as empresas não utilizem MA, os exemplos citados mostram situações que aconteceram na prática e que podem ocorrer, independentemente do método utilizado.

Na empresa “A”, o gerente de vendas solicitou ao Departamento de Informática que disponibilizasse no sistema de gestão uma funcionalidade que fornecesse um acompanhamento de cada pedido de venda emitido pela empresa, de acordo com suas necessidades. O departamento de informática solicitou ao gerente de vendas que redigisse essas necessidades para que pudessem ser implementadas. Nesse contexto, o gerente de vendas da indústria assumiu o papel de cliente sênior, enquanto o Departamento de Informática assumiu o papel da equipe de desenvolvimento.

A Figura 5.4 mostra o documento redigido pelo cliente sênior, entregue à equipe de desenvolvimento, representando a funcionalidade por ele desejada.

Nesse documento, o cliente sênior indicou quais as informações que deseja obter para cada pedido de venda emitido, tais como “N. DO PEDIDO”, “EMPRESA”, “PRAZO ENTREGA”, “OBSERVAÇÃO” e as datas e horários de chegada e saída do pedido em cada departamento, como por exemplo:

“COMERCIAL CHEG. HORA SAÍDA HORA”

Observando a Figura 5.4 é possível perceber também que o cliente sênior focou apenas no resultado que ele espera obter do sistema. Em sua especificação não são citadas situações como liberações, faturamentos e expedições parciais, as quais podem ocorrer sem critério de seqüência, situações essas que são de total conhecimento dele e são executadas pelos funcionários de cada departamento, que seriam, no caso, clientes representativos. Apenas foram especificadas informações que são de seu interesse próprio, tais como dados de entrada e saída do pedido nos departamentos comercial, custos e outros, não se atentando, além das situações citadas acima, de como é o processo de cada um desses departamentos, por exemplo, reprovações e revisões do pedido no departamento de custo. Outro fato não atentado pelo cliente sênior é que, embora mencionado o termo “N. DO PEDIDO” na especificação da funcionalidade (Figura 5.4), esse ainda não existe nas primeiras etapas da especificação, pois essas etapas tratam justamente a aprovação da venda para a geração do Pedido. O cliente está tão focado no que espera obter, que detalhes das funcionalidades acabam não sendo relatados.

A Figura 5.5 é outro exemplo que mostra funcionalidades descritas pelo cliente sênior da empresa “B”. O proprietário da empresa, querendo melhorar as atividades de sua empresa, solicitou a uma empresa de desenvolvimento de software um sistema que gerencie, de forma simplificada, as tarefas diárias da empresa. Foi solicitado ao proprietário da empresa “B” que descrevesse suas necessidades, relacionadas às atividades da empresa, e suas expectativas com relação ao sistema. O proprietário forneceu um documento, do qual dois trechos são mostrados na Figura 5.5.

A B

Figura 5. 5 - Funcionalidades descritas pelo proprietário da empresa "B".

Assim como no exemplo anterior (Figura 5.4), verifica-se a escassez de informações para implementação do sistema. Embora os sistemas de gestão empresarial tenham funcionalidades comuns à maioria das empresas, alguns detalhamentos são importantes. Na Figura 5.5 item (B), por exemplo, não foram fornecidos detalhes de como são feitos os movimentos nela mostrados.

Nesses dois exemplos, mesmo não utilizando os artefatos da Tabela 5.1 e não utilizando MA, foram mostradas situações em que a atividade IFC atua de forma positiva para evidenciar tais problemas, que podem causar impacto negativo no desenvolvimento do produto.

Artefatos de entrada para a atividade: Artefatos destacados em negrito na Tabela 5.1,

de acordo com o método utilizado.

Participantes: Cliente sênior, cliente representativo, testador e um outro membro da

equipe de desenvolvimento.

Como mostrado no Capítulo 4, mesmo com o DOT, o testador exerce atividades importantes no projeto. Ele possui maior facilidade em contextualizar e identificar possíveis causas de problemas. Essa atividade é realizada em dupla, tendo os mesmos princípios da programação em pares do XP. A presença de dois membros da equipe evita que as informações e sua compreensão fiquem amarradas somente a uma pessoa. Quando somente uma pessoa detém informações importantes, mesmo que essas estejam registradas, a equipe torna-se dependente dessa pessoa. Essa situação deve ser evitada. Outro incentivo à presença de dois membros da equipe nas reuniões é o fato que haverá duas pessoas analisando simultaneamente a funcionalidade, existindo uma constante

inspeção sobre os pontos discutidos.

Como: A atividade IFC consiste na realização de reuniões junto a cada cliente

representativo da organização responsável pelas funcionalidades do projeto. Essas reuniões têm como objetivo validar as funcionalidades correspondentes ao cliente representativo, sendo que o mesmo pode corrigir, acrescentar ou remover funcionalidades. Nessas reuniões deve-se compreender e obter todas as informações necessárias para implementação das funcionalidades, procurando esclarecer questões do tipo “o que será feito?” , “por quê?”, “como será feito?” e “com o que será feito?”. Essas informações são relevantes para a atividade ECT que é a terceira atividade do processo.

Inicialmente, as funcionalidades devem ser identificadas. Conforme mencionado na Seção 5.2, uma funcionalidade pode se referir a um requisito ou a um conjunto de requisitos, podendo um artefato conter uma ou mais funcionalidades, como uma funcionalidade pode estar descrita em um conjunto de artefatos. Identificadas as funcionalidades, são identificados os responsáveis por cada funcionalidade para que as reuniões possam ser agendadas e executadas.

Ao fim dessas reuniões, o cliente representativo deve estar de acordo com as funcionalidades correspondentes a ele. Na ocorrência de problemas com as respectivas funcionalidades, os participantes da reunião devem solucioná-los. Essas ocorrências devem ser registradas no Formulário de Relato de Ocorrências – IFC, mostrado no Apêndice C. Esse registro, além de documentar o ocorrido, servirá como dado histórico para futuros projetos.

Novas funcionalidades podem ser identificadas durante as reuniões. Essas novas funcionalidades devem ser registradas no artefato pertinente. Caso o cliente representativo com o qual esteja sendo feita a reunião no momento seja o responsável por essas novas funcionalidades, elas devem ser validadas nesse momento. Caso contrário, deve-se realizar uma reunião da atividade IFC com os clientes representativos apropriados, mesmo que uma reunião com eles já tenha ocorrido.

Aconselha-se agendar a maior quantidade de reuniões possíveis em uma mesma data, procurando agrupar as reuniões que possuem clientes representativos envolvidos em uma mesma área. Essas ações proporcionam: diminuição do custo de deslocamento da

equipe ou do cliente; diminuição do custo, relacionado ao cliente, referente à quantidade de saídas do funcionário de suas funções diárias; o entendimento do projeto como um todo é facilitado, pois todas as idéias estão recentes.

Quando: O início da realização das reuniões se dá tão logo se tenha o registro das

versões iniciais das funcionalidades do sistema.

Saídas: Funcionalidades validadas quanto às expectativas do cliente, as quais são

tratadas diretamente com cada responsável.

Observações: Em pequenas organizações, nas quais o escopo do projeto é pequeno,

podem-se encontrar situações em que o cliente sênior é o próprio cliente representativo. Mesmo que o levantamento das versões iniciais das funcionalidades tenha sido obtido através do mesmo cliente com o qual será feita a validação, a execução dessa atividade se mantém, pois, em um segundo momento, os membros responsáveis da equipe de desenvolvimento e esse cliente estarão mais amadurecidos em relação a tais funcionalidades.

5.3.3. Atividade IFA – Inspeção das Funcionalidades nos