Revista MSDN Magazine Edição 04 - Por que usar MSF?

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (1)  (0)

Artigo Originalmente Publicado na MSDN Magazine Edição 04

msdn04_capa.JPG

Clique aqui para ler todos os artigos desta edição

 

Por que usar MSF?

por Fábio Camara

 

Este artigo tem por objetivo contestar a utilização de ferramentas como metodologia de controle de projetos, bem como explicitar as razões para a utilização do MSF (“Microsoft Solutions Framework”) no desenvolvimento de projetos.

Apesar de a sigla representar o título “Microsoft Solutions Framework”, o MSF não é uma ferramenta da Microsoft que você possa comprar em uma revenda autorizada. Defino MSF como um conjunto de “Best Practices” para a condução de um projeto de software – principalmente do ponto de vista gerencial. O MSF foi criado em 1994 a partir de um conjunto das melhores técnicas utilizadas pela Microsoft Consulting Services e pelo centro de desenvolvimento de produtos da Microsoft.

Programas versus Projetos

Compreendemos “Programa” como um conjunto de instruções preestabelecidas que são executadas por um computador. Há tempos escuto e leio diversas definições sobre o que é um projeto. Lembro-me de que gostava de limitar a definição de “projetos” a um trabalho com escopo previamente definido, ou seja, com início, meio e fim. Porém, atualmente essa definição não me parece mais suficiente. Ao contrário do que ocorre com os programas, em projetos não possuímos instruções preestabelecidas (ainda que às vezes nos enganemos a respeito disso). Além disso, muitas variáveis influenciam os projetos e todas elas convergem para um único ponto central: o ser humano.

A partir desses aspectos, questiono a validade das ferramentas ou técnicas que impõem instruções ou regras preestabelecidas, pois elas desconsideram o aspecto humano envolvido nos projetos, e proponho a seguinte questão: é possível direcionar projetos com êxito sem levar em conta os participantes que neles se envolvem?

A relação humana com os projetos é tão determinante e exclusiva que, sem dúvida, um projeto nunca será igual a outro (nem similar, mesmo que desenvolvido pelo mesmo grupo de pessoas).

Também não posso deixar de ressaltar que, atualmente, acredito não existirem mais (se é que um dia existiram ou foram imposição dos fornecedores) projetos de software com início, meio e fim, definidos com muita antecedência, como desejam as metodologias.

Então, por que exigir que projetos assumam a dimensão de programas, se na prática eles não são?

Antes de estabelecer a polêmica (e assumindo uma postura que pode ser vista inclusive como antiacadêmica), comprometo-me a fornecer uma posição clara, transparente e única: A receita para a construção de projetos é escolher pessoas que compreendam e utilizem a trilogia “processos – papéis – comunicação” com inteligência.

A Trilogia

Após aceitarmos que os projetos são, na verdade, o gerenciamento eficiente de pessoas, a técnica a ser utilizada deverá ser criativa e específica – desde que baseada na trilogia “comunicação - processos - papéis”. Dessa forma, quebramos o paradigma de receitas de bolo para projetos (normalmente, do tipo “one size fits all”, ou em português: “um tamanho único que serve a todos”).

Existem propostas com ferramentas caríssimas. Elas tentam prever tantas coisas genéricas que a especificação do projeto é mais onerosa que sua construção. É inaceitável isso, pois seria o mesmo que dizer que a planta de um edifício é mais cara que sua construção. De fato, acaba ocorrendo uma espécie de ilusão coletiva: todos fingem fazer tudo que a metodologia exige.

Neste quesito, parabenizo a Microsoft pelos ensinamentos sobre o MSF. Do ponto de vista gerencial, o MSF funciona como um conjunto de formas canônicas para a condução de um projeto de software. Minha intenção aqui não é vender uma ferramenta, mas sim apresentar técnicas e macetes para que você administre corretamente seus projetos de software.

A base do MSF é a trilogia. Você pode usar as técnicas que desejar, mas recomendo que utilize as que você já domine, desde que respeite as adaptações necessárias a cada projeto específico. Entretanto, deixe muito claro a todos os envolvidos do projeto as formas e regras de comunicação, os processos estabelecidos e os papéis destinados a cada um.

Comunicação

É impressionante como estamos sempre ao lado de pessoas. Passamos o dia inteiro trabalhando com elas e conversando sobre assuntos importantes, como filmes, futebol e até novelas, mas não falamos sobre o projeto. É mais fácil gastar horas procurando uma informação (ou pior, deduzi-la) que discutir com o companheiro de projeto ao lado.

Devem existir centenas de explicações filosóficas para esse fenômeno; deixo-as para os intelectuais e psicólogos. Minha prática sobre este assunto é:

- Escreva todas as informações importantes “do e para” o projeto, coloque-as em locais visíveis a todos (como bandeiras penduradas).

- Faça reuniões periódicas, preferencialmente semanais, com todo o time do projeto. Discuta sobre assuntos pertinentes ao projeto e procure ouvir a opinião dos participantes sobre os pontos de risco. Anote tudo, distribua em forma de ATA e peça aos participantes que homologuem o texto.

Este pilar trilógico é o mais livre e criativo dos três, faça da melhor forma ao seu projeto.

Papéis

Este é o tópico mais importante e original da proposta MSF. Eu até ousaria escrever que os papéis são a base da trilogia (reconheço o risco desta afirmativa).

O conceito consiste em determinar a certas pessoas-chave do projeto a responsabilidade de papéis com escopos definidos. Esses papéis são equilibrados e distribuídos de forma a facilitar a identificação de riscos no projeto e sua correta ação para a solução.

Os papéis são: Program Management, Product Management, User Experience, Tester, Release Management e Development.

Development: são os desenvolvedores propriamente ditos. É aconselhável escolher um desenvolvedor para team leader, que participe das reuniões e transmita as informações aos demais. Aconselhamos também que este team leader seja um programador-sênior, que funcione como direcionador de assuntos técnicos especialistas.

Release Management: quanto custa um dia de 10 desenvolvedores parados porque o servidor centralizador de códigos fontes está com problemas, ou porque a rede tem vírus, ou por qualquer outro problema? Este é o responsável por garantir toda a infra-estrutura necessária ao bom andamento do projeto.

Tester: não existe projeto sério sem que haja um trabalho fundamentado em técnicas e métodos para testes. Ferramentas de automação de testes, Units Test, testes de carga, tunning de aplicativo, tunning de banco de dados e muitos outros tópicos que necessitam de um papel responsável e comprometido no projeto para endereçá-los.

User Experience: é o usuário propriamente dito, em outras palavras, é quem usará o programa e quem sabe questionar a praticidade das funcionalidades por ele ofertadas. Não existe programa sem usuário e é erradíssimo agir sem levar isso em conta. Um macete é escolher um usuário super exigente, quanto mais crítico melhor será o resultado final.

Product Management: em todas as relações de negócios, sempre haverá uma espécie de vendedor, que também funciona como advogado do cliente. Este papel é responsável por ouvir clientes, pesquisar e direcionar as funcionalidades contidas no aplicativo. Eventualmente, ele se tornará também o melhor consultor e vendedor do projeto.

Program Management: pense em alguém que fotografa, vê todas as situações e imediatamente alerta os participantes a respeito de cada particular. É a eminência parda do time. Conhece negócios, tecnologia e gestão de pessoas. Pode significar diretamente o sucesso ou o fracasso de um projeto. É o responsável, o apaziguador, o direcionador, o esclarecedor.

O MSF defende que esses papéis não sejam hierarquizados, entretanto, na prática, o Program Management  assume a posição de liderança.

Nas diversas fases do projeto, são feitas reuniões, cuja periodicidade é combinada entre os “papéis” do projeto com o intuito de nivelar as informações sobre os trabalhos. Os resultados dessas reuniões são chamados Status Report e Risk Analisys.

Processos

É mais fácil perceber a ausência do que a existência de processos em seu projeto. Este assunto é digno das “cadeiras” de administração e pode ser facilmente comparado a O&M – Organização & Métodos.

É fundamental percebermos que os processos devem ser conhecidos e adotados por todos os participantes do projeto. Não adianta ele ser pensado somente pelo gestor. Do contrário, a rotina criativa e direcionada necessária ao projeto vai levar o gestor à exaustão e, na ausência dele, o caos ao projeto.

É o mesmo que afirmar que determinados recursos são insubstituíveis. Em princípio, isso pode até parecer interessante, principalmente se você for o gestor (afinal, é ótimo pensar que você é insubstituível). Os gestores, de fato, entendem que essa relação de dependência não é sadia e elevam desnecessariamente o risco do projeto.

Independentemente da metodologia a ser adotada para o projeto, os participantes não podem ficar à espera de um gestor determinístico que direcione toda e qualquer ação. Essa “entidade” gestora deve proporcionar a todos os participantes do projeto, antecipadamente, os métodos para a ação, sem deixar de preservar as capacidades críticas e evolutivas de cada participante. A trilogia demanda unicidade, e não há a possibilidade de ser diferente. Em outras palavras, sem processos seu projeto será um fracasso.

Ciclo de Vida

Seu projeto possui implicitamente um ciclo de vida, mesmo que você não faça a menor idéia do que seja isso. Mesmo nos desenvolvimentos mais simples existem as 3 fases distintas que devem possuir marcos que determinam sua seqüência: um momento em que irá ouvir um solicitante, outro que organizará estas informações e finalmente o que irá implementar. Eis seu primitivo e tácito ciclo de vida.

A proposta do MSF é a separação em 4 fases: visão, especificação, desenvolvimento e estabilização (MSF Process Model 1.1). Cada uma dessas fases possui uma proposta clara e simples e contempla todas as necessidades relacionadas ao desenvolvimento de um projeto de software. O surpreendente dessas fases é que você é livre para utilizar os métodos e documentos que preferir, desde que eles lhe proporcionem condições de satisfazer a idéia central por trás de cada fase.

Na primeira fase, visão, o objetivo é obter os requisitos macros para permitir o dimensionamento do projeto. Nesta fase, definimos o time do projeto, elaboramos o escopo, construímos a primeira versão do cronograma e, uma sugestão pessoal: o dividimos em módulos (separados por complexidade), definindo as entregas com base na complexidade (do mais simples ao mais avançado).

A meu ver, a fase de especificação é que mais gera polêmica entre os participantes do projeto. Steve MacConnell, um dos maiores estudiosos deste assunto, dedica vários capítulos de seu livro “Code Complete” à necessidade e importância dos requisitos, indispensáveis à construção de um software.

Muito se discute sobre a qualidade de um software estar diretamente relacionada à qualidade de sua equipe de testes. Bem, por analogia, um projeto tem início, meio e fim. Em qual dessas etapas estariam os testes? No fim. Então, concluímos que no final do desenvolvimento existirão pessoas “mágicas” que consertarão todos os desvios do projeto. Na prática, se os requisitos do projeto foram bem especificados e compreendidos pelo time, serão eles que direcionarão todo o desenvolvimento do projeto (inclusive os testes). Em nossa analogia, a especificação seria a primeira etapa – o início – é nessa etapa que estão comprometidas todas as etapas seguintes.

Nessa fase, utilize as melhores técnicas que possuir para especificar os requisitos. Embora a sugestão do MSF seja a notação UML, fique à vontade para usar análise essencial ou outra. Simplesmente use alguma.

A terceira fase de nosso ciclo, desenvolvimento, é a mais popular. Afinal, todos em seu projeto gostam de implementar e, muito provavelmente, consideram as fases anteriores “perda de tempo”. Independentemente dessas considerações, a codificação não é uma manifestação artística. Se em seu projeto os programadores codificam cada um ao seu estilo, você está em sérios apuros. Os times de desenvolvimento que trabalham dessa maneira têm baixo índice de reutilização, extrema dificuldade de manutenção e gigantescos problemas para substituir programadores. Programar não é tarefa para “artistas”. Existem técnicas e regras que, quando aplicadas, permitem um código claro e objetivo. Defina, documente e ensine ao time de desenvolvimento essas técnicas e regras. Aplique periodicamente uma revisão de código nos programas de seu projeto e exija a adequação dos desvios encontrados pelo autor dos códigos “fora da regra”. Se você proceder assim, o projeto estará sob o seu controle e não haverá programadores insubstituíveis.

A fase final, estabilização, consiste em constatar se as fases antecedentes foram bem-sucedidas. É a técnica de testar, avaliar, criticar e corrigir. É a capacidade de identificar em qual fase ocorreu o desvio e retomar o ciclo a partir deste ponto. Por fim, é a fase que permite a revisão constante de seu cronograma, a fim de prever os ajustes de acordo com os resultados obtidos.

Conclusões

Com essas práticas simples e com pessoas inteligentes, criativas e comprometidas, todos os projetos terão suas adaptações e ajustes necessários para um caminho de resultados reais, palpáveis.

Não há ferramenta ou técnica metodológica capaz de substituir o ser inteligente em um projeto de software, pela própria compreensão do que é método. No dicionário de língua portuguesa, método é definido como “procedimento, meio ou técnica para ser fazer alguma coisa de acordo com um plano”. Metodologia é o estudo dos métodos, e não a imposição de métodos. Metodologia é a capacidade crítica de avaliação sobre uma técnica, ou seja, avaliar se ela foi a melhor forma de atingir o resultado esperado.

O MSF lhe permite respeitar as melhores capacidades de seu time e lhe possibilita adequá-lo para maior produtividade e qualidade.

As informações apresentadas aqui não são técnicas setorias específicas adquiridas em instituições de ensino. São vivências maturadas globais, frutos da união de algumas especificidades técnicas, administrativas e humanas.

Sucesso em seus projetos.

 

Links sobre o assunto:

 

http://www.stevemcconnell.com/cc.htm

http://www.microsoft.com/traincert/syllabi/1846AFinal.asp

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/innsol/msfrl/default.asp

http://www.microsoft.com/technet/treeview/default.asp?url=/technet/itsolutions/tandp/innsol/msfrl/MSFTM31.asp

 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Ficou com alguma dúvida?