Augusto Vespermann » Gerência de Projetos

Maré de Agilidade – Evento sobre desenvolvimento ágil em Vitória

Augusto Vespermann — Fri, 30 Apr 2010 10:53:47 +0000

Number of View: 313

O Evento

Objetivos

O Maré de Agilidade mantém-se fiel a seu objetivo de disseminar Metodologias Ágeis em todas as regiões do país. Assim, chega a Vitória em sua sexta edição.

Porém, mais que disseminar conhecimento, o Maré de Agilidade agiliza o networking, favorece parcerias, potencializa o fechamento de negócios e fortalece a empregabilidade, principalmente na área de Tecnologia da Informação.

Público Alvo

Entendemos como público alvo qualquer pessoa interessada em Metodologia Ágil. Acreditamos que, mais especificamente, esse público alvo seja composto,principalmente, por estudantes, profissionais e empreendedores nos ramos de tecnologia, publicidade, marketing, administração, engenharia, ciência da computação e áreas afins.

Justificativa

O Maré justifica-se pela formação e pela informação.

Pela informação, justifica-se pela dissiminação de conhecimento das metodologias ágeis e cases de sucesso.

Pela formação, justifica-se pela criação, fomentação e intensificação da cultura de metodologias ágeis na sede do evento, gerando, assim, oportunidades de networking, trocas de know-how e expertise, negócios e parcerias.

Programação

Confira aqui a programação completa do Maré Vix!

08:00h – Recepção, credenciamento e coffee break

hora do lanche reforçado e início do networking com os demais congressitas

09:00h – Abertura oficial

apresentação oficial do evento

09:20h – Palestra: Um Produto em duas semanas

por Guilherme Silveira, da Caelum

10:20h – Palestra: Negociação de contratos de projetos ágeis

por Paulo César M Jeveaux, da Giran

11:20h – Palestra: TDD e Zero Defeito

por Fabrício Matos, da Qualidata

12:30h – Parada para o almoço

uma rápida parada para o almoço, lembrem-se: o evento retorna em 1:30h

14:00h – Palestra: Domain-Driven Design

por Denis Ferrari, da Mindworks

15:00h – Palestra: a definir

por Guilherme Chapiewski, do Yahoo!

16:00h – Coffee break

outro lanche reforçado! E mais networking

16:30h – Mesa redonda

com Guilherme Silveira, Guilherme Chapiewski, Fabrício Matos, Paulo César M Jeveaux e Denis Ferrari

17:30h – Sorteios e confraternização

encerramento do evento

Quando

Dia 29/05/2010 à partir de 08:00h

Onde

Faculdade Faesa da Avenida Vitória – site.faesa.br

Veja o endereço completo e saiba como chegar.

Mais informações www.mare-vix.com

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Tradução do CMMI versão 1.2 para desenvolvimento de projetos

Augusto Vespermann — Fri, 16 Apr 2010 15:26:41 +0000

Number of View: 459

Este trabalho tem como objetivo único facilitar a divulgação de um modelo de melhoria de processos que vem sendo muito utilizado e tem trazido resultados positivos àqueles que o estão usando.

Foi observado que um dos principais problemas de divulgação do CMMI das práticas do modelo reside no fato do mesmo estar escrito em inglês. Diante disto, decidiu-se traduzi-lo e torná-lo público, esperando com isto facilitar o acesso de mais pessoas ao assunto.

Faça o download do CMMI Versão 1.2 em português

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Estágios do CMMI

Augusto Vespermann — Sun, 11 Apr 2010 11:03:15 +0000

Number of View: 485

O CMMI possui duas representações: “contínua” ou “por estágios”. Estas representações permitem à organização utilizar diferentes caminhos para a melhoria de acordo com seu interesse.

Representação Continua

Possibilita à organização utilizar a ordem de melhoria que melhor atende os objetivos de negócio da empresa. É caracterizado por Níveis de Capacidade (Capability Levels):

Nível 0: Incompleto (Ad-hoc)
Nível 1: Executado (Definido)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização (ou Optimizado)

Representação Por Estágios

Disponibiliza uma seqüência pré-determinada para melhoria baseada em estágios que não deve ser desconsiderada, pois cada estágio serve de base para o próximo. É caracterizado por Níveis de Maturidade (Maturity Levels):

Nível 1: Inicial (Ad-hoc)
Nível 2: Gerenciado / Gerido
Nível 3: Definido
Nível 4: Quantitativamente gerenciado / Gerido quantitativamente
Nível 5: Em otimização

Áreas de Processo

O modelo CMMI v1.2 (CMMI-DEV) contém 22 áreas de processo. Em sua representação por estágios, as áreas são divididas da seguinte forma:

Nível 1: Inicial (Ad-hoc)

Não possui áreas de processo.

Nível 2: Gerenciado / Gerido

Gerenciamento de Requisitos – REQM (Requirements Management)
Planejamento de Projeto – PP (Project Planning)
Acompanhamento e Controle de Projeto – PMC (Project Monitoring and Control)
Gerenciamento de Acordo com Fornecedor – SAM (Supplier Agreement Management)
Medição e Análise – MA (Measurement and Analysis)
Garantia da Qualidade de Processo e Produto – PPQA (Process and Product Quality Assurance)
Gerência de Configuração – CM (Configuration Management)

Nível 3: Definido

Desenvolvimento de Requisitos – RD (Requirements Development)
Solução Técnica – TS (Technical Solution)
Integração de Produto – PI (Product Integration)
Verificação – VER (Verification)
Validação – VAL (Validation)
Foco de Processo Organizacional – OPF (Organizational Process Focus)
Definição de Processo Organizacional – OPD (Organizational Process Definition)
Treinamento Organizacional – OT (Organizational Training)
Gerenciamento Integrado de Projeto – IPM (Integrated Project Management)
Gerenciamento de Riscos – RSKM (Risk Management)
Análise de Decisão e Resolução – DAR (Decision Analysis and Resolution)

Nível 4: Quantitativamente gerenciado / Gerido quantitativamente

Desempenho de Processo Organizacional – OPP (Organizational Process Performance)
Gerenciamento Quantitativo de Projeto – QPM (Quantitative Project Management)

Nível 5: Em otimização

Inovação Organizacional e Implantação – OID (Organizational Innovation and Deployment)
Análise Causal e Resolução – CAR (Causal Analysis and Resolution)

Histórico de Avaliações

Até o ano de 2002, os EUA tinham realizado 1,5 mil avaliações de CMMI, a Índia feito 153, o Reino Unido 103 e o Brasil apenas 15. Em 2004 a TATA Consultancy Services (empresa indiana) alcançou o nível 5 em todas as unidades da empresa, tendo sido avaliada inclusive a unidade brasileira (a primeira empresa presente no Brasil a receber o nível máximo na avaliação).

Entre abril de 2002 e junho de 2006 foram conduzidas 1581 avaliações em 1377 organizações. Segue abaixo o resultado obtido pelas empresas na avaliação (resultados encaminhados para o SEI até 30 de junho de 2006):

18,2%: nível 5 (Optimizing);
4,4%: nível 4 (Quantitatively Managed);
33,8%: nível 3 (Defined);
33,3%: nível 2 (Managed);
1,9%: nível 1 (Initial);
8,4%: sem qualificação (Not Given).

No Brasil, as seguintes empresas conseguiram realizar a certificação até o final, ou seja, alcançaram o nível 5 do CMMI (por ano da certificação):

2004

TCS (TATA Consultancy Services) Brazil^[1]

2005

IBM Brazil^[2]
Stefanini IT Solutions
EDS – Electronic Data Systems^[3]

2007

Ci&T^[4]
CPM Braxis^[5]

2009

Instituto Atlântico^[6]

Fonte: Wikipedia

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Como a Microsoft expandiu o Agile para se adequar ao CMMI Nível 3

Augusto Vespermann — Sat, 10 Apr 2010 11:19:53 +0000

Number of View: 286

David J. Anderson – Microsoft Corporation

Resumo

Os adeptos de metodologias ágeis se orgulham dos processos de conhecimento altamente produtivos, responsivos, pouco cerimoniosos, leves e de conhecimento tácito com pouco gasto, planejamento adaptável e geração iterativa e freqüente de valor. Assume-se freqüentemente que os processos compatíveis com CMMI devem ser pesados, burocráticos, lentos, altamente cerimoniosos e orientados a um plano. Os desenvolvedores ágeis freqüentemente percebem com ceticismo as iniciativas de melhoria de processos formais como ineficiência gerada pelo gerenciamento, que se interpõe à produtividade.

Na Microsoft, adotamos os ensinamentos de W. Edwards Deming e estendemos nosso método MSF para Desenvolvimento Ágil de Software para se ajustar aos requisitos do CMMI Nível 3. O resultado, MSF para o Aprimoramento do Processo CMMI, é um método de planejamento adaptável e altamente iterativo, com pouca documentação e fortemente automatizado por meio de ferramentas. Ele permite o gerenciamento e a organização de engenharia de software por meio do uso de métricas ágeis tais como velocidade e fluxo cumulativo, porém com uma dimensão adicional de entendimento de variação – adaptado dos ensinamentos de Deming.

Essa é a história de como a mistura de Deming e Agile produziu uma solução CMMI leve para desenvolvedores .Net em toda parte.

Introdução

Em agosto de 2004, nós (na Microsoft) começamos a desenvolver uma metodologia para o novo produto, Team System, que seria compatível com o CMMI (Capability Maturity Model Integration) do SEI (Software Engineering Institute) [SEI 2002]. Nesse momento, não imaginamos que a solução final seria vista como um método ágil. Assumimos que o mundo do CMMI e o mundo ágil eram como óleo e água. O CMMI e seu antecessor, o Software CMM [SEI 1993], foram amplamente associados a negócios de contratação, aeroespaciais e de defesa do governo – um mundo de programas grandes e de longa duração, freqüentemente em sistemas importantes para a vida, com exigências governamentais de auditabilidade e rastreabilidade.

Muitos desenvolvedores de software geralmente estão desconfiados do processo. O processo geralmente se coloca em seu caminho e retarda o andamento do desenvolvimento de software a um nível frustrante. O CMMI está associado em suas mentes a tais iniciativas de processo. Chegamos ao início do projeto do método MSF para Aprimoramento do Processo CMMI® [Microsoft 2005a] com preconceitos similares.

Para fornecer algum histórico, a Microsoft Consulting Services vem oferecendo treinamento em gerenciamento de projetos sob a marca MSF (Microsoft Solutions Framework) desde 1992. O MSF possui uma longa história e um corpo de conhecimento construído durante mais de uma década. O MSF v3.0 incorporou o conhecimento interno da Microsoft e fontes externas. Ele incorporou muito da ciência de gerenciamento estabelecida no final do século XX e abrangeu os conceitos de contabilidade de equipe, compartilhou responsabilidade, capacitação, delegação, pensamento de sistemas e muitos outros aspectos da prática de gerenciamento geral. O MSF não se parece muito com a tradicional orientação de gerenciamento de projetos de engenharia de software. Em muitos aspectos é muito ágil. A equipe do MSF v4.0 tinha de respeitar a história do MSF ao tentar criar um método que poderia corresponder aos requisitos do CMMI.

Nossa interpretação da essência do desenvolvimento de software ágil era que este se torna possível pela confiança – acreditar que os desenvolvedores fazem a coisa certa e conquistar a confiança dos clientes por meio de entrega freqüente e atenção ao feedback. Isso fornece a pausa e a capacitação necessárias para permitir que boas coisas aconteçam. Por outro lado, a indústria aeroespacial e de defesa do governo pareceu ser um local em qual faltou confiança e dependeu da verificação de auditoria – um lugar onde nada aconteceu sem revisão e aprovação do comitê – aprovação esta sendo exigida freqüentemente em todo o ciclo de vida. Tudo deve ser delineado bidirecionalmente de modo finamente granulado para facilitar a auditoria. Além disso, a natureza auto-organizativa com autonomia do desenvolvimento de software ágil pareceu oposta a planejar o plano, planejar o trabalho, trabalhar o plano, abordagem de comando e controle, que parecia ser parte do CMMI. Parecia que o método CMMI precisava ser um método de grande planejamento antecipado e que não havia oportunidade de reutilizar nenhum trabalho feito para o método MSF para Desenvolvimento de software Agile [Microsoft 2005b] já em desenvolvimento.

Algumas tentativas anteriores de executar o ágil dentro de uma estrutura CMMI, [por exemplo, Alleman 2003], ofereceram essencialmente soluções pontuais, como a capacidade de utilizar alguns aspectos de programação extrema dentro de um ambiente de controle e comando otherwise, grande planejamento antecipado, não adaptável. Isso pareceu enfatizar a diferença filosófica entre os dois mundos. O que procurávamos alcançar era um método de ciclo de vida pleno que fosse realmente ágil, mas correspondesse aos requisitos do CMMI (no mínimo nível 3). O SEI [Paulk 2001, 2002] tem procurado oferecer tal orientação mais notavelmente neste ano [Konrad 2005]. Entretanto, essa orientação tende a ser focalizada em soluções pontuais como o XP, ou de alto nível, filosóficas e difíceis de implementar no sentido de um ciclo de vida pleno e genérico. A literatura existente resumiu que o CMMI e o ágil eram compatíveis, mas falharam em fornecer detalhes ou exemplos específicos.

Alcançamos nossa meta de um método CMMI ágil estendendo o método MSF para Desenvolvimento de software Agile para que se ajustasse. Temos cobertura de 20 das 25 áreas de processo, com exceção do Gerenciamento de Acordo do Fornecedor, Gerenciamento Integrado do Fornecedor, Foco no Processo Organizacional, Ambiente Organizacional para Integração e Treinamento Organizacional. As áreas de processo no escopo dos níveis 2 e 3 no modelo CMMI são totalmente cobertas, e as dos níveis 4 e 5 têm cerca de 50% de cobertura.

O que tornou isso possível? Qual foi a ponte entre o mundo CMMI e a filosofia do desenvolvimento de software ágil? A resposta reside nos ensinamentos de W. Edwards Deming. A Teoria do Conhecimento Profundo de Deming baseada em um entendimento da variação natural em processos e sua análise com controle estatístico de processosfoi a chave para liberar uma abordagem do CMMI ágil do ciclo de vida completo.

Deming e Ágil

A filosofia base de W. Edwards Deming sobre o gerenciamento é baseada no conceito de feedback. O ciclo de Deming de PDCA (Planejar-Fazer-Verificar-Agir). Deming utiliza esse ciclo de feedback para orientar mudanças com base em análise estatística objetiva. Além de técnicas objetivas rígidas como o controle estatístico, Deming também introduziu orientação subjetiva mais maleável com base em sistemas que pensam com seus 14 pontos de gerenciamento [Deming 1982]. Dos 14 pontos, os de mais interesse à comunidade ágil são:-

3. Cessar a dependência do controle de qualidade para alcançar qualidade, e ao invés disso se concentrar na garantia de qualidade em todo o ciclo de vida.
4. Conquistar confiança e fidelidade dos fornecedores
6. Treinamento sobre o trabalho
7. Liderança
8. Prosseguir sem medo
9. Quebrar barreiras entre
departamentos
12. Remover barreiras para se orgulhar da mão-de-obra, focalizar o gerenciamento na qualidade em vez de números da produção

O pensamento de Deming está muito alinhado ao manifesto ágil e as práticas de muitos métodos ágeis. O número 3 poderia ser comparado à prática de desenvolver o teste primeiro, por exemplo. Ágil compreende tudo o que se refere à criação de confiança entre desenvolvedores e clientes (no. 4). Práticas, como programação em pares, encorajam o treinamento durante o trabalho (no. 6). Suporte a conceitos, como passo sustentável, e à transparência de geração de relatórios dentro de equipes auto-organizativas que prosseguem sem medo (no. 8). Funções generalistas e trabalho de equipe colaborativo quebram barreiras entre departamentos (no. 9). Ciclos curtos de entrega iterativa em que todos na equipe verão o trabalho finalizado e o demonstrarão ao cliente a cada poucas semanas, removendo barreiras em se orgulhar da mão-de-obra e concentrando-se na qualidade (no. 12). A qualidade, de acordo com Deming, é definida pelo cliente e não pela especificação (ou seja, a alteração deve ser adotada se for o que o cliente quiser). Isso é muito ágil.

Deming ensinou que a qualidade é conformidade ao processo em vez de conformidade à especificação. Em vez de mensurar a conformidade à especificação utilizando departamentos de controle de qualidade, é melhor criar garantia de qualidade no processo e mensurar a conformidade ao processo. A implicação é que se você estiver fazendo coisas do modo correto, então a coisa certa será produzida e o cliente ficará feliz. Esse é o gerenciamento de 2ª ordem — gerenciamento do processo.

Teoria do Conhecimento Profundo

A Teoria do Conhecimento Profundo tenta fornecer um mecanismo objetivo para mensuração se um processo está sob controle – se uma equipe está fazendo a coisa certa ou não. A teoria é muito simples: procura entender a variação natural nas tarefas que os trabalhadores devem realizar e mensura a variação. Utilizando a matemática desenvolvida por Walter Shewhart [Shewhart 1939], os limites de controle superior e inferior são definidos. Se o processo estiver variando dentro dos limites de controle, então se diz que o processo está sob controle. Sob controle significa essencialmente que o processo está em execução conforme projetado e não é influenciado indevidamente por fatores externos fora do controle de gerenciamento imediato. Quando o processo está variando fora dos limites de controle, então se diz que está fora de controle. Em outras palavras, algum fator externo afetou o desempenho do processo e colocou a qualidade do resultado em risco.

A epifania de Deming

O CMMI é um modelo para melhoria do processo que tem por objetivo levar uma organização a um nível em que o aprimoramento contínuo em produtividade e qualidade seja possível [Chrissis 2003]. Essa filosofia básica é baseada no trabalho de W. Edwards Deming [Deming 1982]. Entretanto, o modelo de 5 níveis que foi apresentado pelo CMM de Software original para permitir que a avaliação da maturidade em empreiteiras governamentais para os contratos da Força Aérea dos Estados Unidos fosse baseada n modelo de fabricação de Philip Crosby [1979] O nome de Crosby é mais associado à definição de qualidade como conformidade à especificação [Crosby 1979]. Portanto, para mensurar a qualidade, alguém devem ter uma especificação completa no início e no final a variação derivada da especificação é mensurada e a qualidade é avaliada. Para projetos de software, o sucesso é mensurado com a utilização da métrica de qualidade, interpretada como entrega de um projeto no momento certo, no devido orçamento, com a funcionalidade acordada. A influência de Crosby no CMM de Software é tão proeminente que não é amplamente apreciado que a filosofia e meta subjacentes do CMMI é alcançar aprimoramento contínuo como descrito e ensinado por Deming.

O modelo de maturidade do CMMI é mapeado ao pensamento de Deming. Os níveis 2 a 4 se referem à criação da capacidade organizacional para eliminar a variação de causa especial e, portanto, evitar erros de gerenciamento n. 1 e n. 2 (consulte a seção após a Figura 3), enquanto o nível 5 fornece aprimoramento contínuo por meio da redução gradual da variação de causa comum. Se o CMMI estivesse realmente enraizado na filosofia de Deming, nos pareceria que deve ser possível criar um método CMMI realmente ágil.

Foi essa constatação, em novembro de 2004, que nos fez abandonar o trabalho feito até então no MSF para Aprimoramento de processo CMMI. Decidimos começar novamente e criar um modelo de processo baseado em nosso método MSF para Desenvolvimento de software Ágil.

Organização do CMMI

O CMMI é tanto um modelo de capacidade quanto um modelo de maturidade. O modelo pode ser implementado em etapas. Essa é a idéia de que uma organização alcança a maturidade nível 2 por meio de todas as práticas pertinentes e então o nível 3, e assim por diante. Também pode ser implementado de modo contínuo, em que a capacidade em práticas individuais é mensurada. Uma organização pode atingir um alto nível de capacidade em uma prática específica, mantendo ao mesmo tempo apenas um nível 2 em outras práticas. É o método em etapas de atribuir níveis de maturidade que é associado ao mercado de contratação governamental Americano e é, portanto, melhor conhecido na América do Norte.

O modelo CMMI atualmente consiste em 25 áreas de processo. Dentro de cada área de processo, um número de metas específicas são enumeradas. Cada meta, por sua vez, possui um conjunto enumerado de práticas específicas. As práticas estão em um nível prescritivo em que descrevem o que deve ser feito e quais artefatos devem ser produzidos como resultado. Por exemplo, o Planejamento de projeto (PP) 2.1 nos pede para”identificar dependências da tarefa” e espera um “Método de caminho crítico CPM ou um gráfico de Técnica de avaliação e revisão de programa (PERT)” [Chrissis 2003] como resultado.

Muitas dessas práticas, como documentadas, seriam inaceitáveis para um desenvolvedor de software ágil. Por exemplo, a subprática 2 do PP 1.1 nos pede para “Identificar os pacotes de trabalho em detalhe suficiente de modo a especificar estimativas do projeto, tarefas, responsabilidades e programação” e continua com “A quantidade de detalhe no WBS nesse nível mais detalhado ajuda no desenvolvimento de cronogramas mais realistas, minimizando, dessa forma, a necessidade de gerenciar reservas”. É muito fácil interpretar isso como requisito para grande planejamento antecipado. O PMC (Monitoramento e controle de projetos) 1.1 nos pede para comparar “a conclusão real de atividades e marcos históricos frente à programação documentada no plano do projeto, identificando desvios significativos oriundos das estimativas no plano do projeto”. Isso soa como planejamento, comando e controle pesado e é antitético ao conceito ágil de auto-organização e alocação de trabalho atrasada. A TS (Solução técnica) 2.2 nos pede para “estabelecer um pacote de dados técnicos” e sugere artefatos como “descrição de arquitetura de produto, requisitos alocados, descrições de componente de produto, características de produto, requisitos de interface, condições de uso” e assim por diante. Novamente, é fácil interpretar isso como um requisito para a documentação pesada. Também prescreve o design antes da codificação, que é detestável para a filosofia de desenvolvimento orientada ao teste extremo, em que o design é emergente via refatoramento.

Além disso, o CMMI tem uma reputação de documentação pesada. Algumas literaturas [Ahern 2005] informam que tantos quantos 400 tipos de documentos e 1000 artefatos são necessários para facilitar uma avaliação.

Alcançando agilidade com CMMI

Uma chave para alcançar mais agilidade com o CMMI é perceber que as práticas são primariamente consultivas ou indicativas somente. Para corresponder a uma avaliação do CMMI, uma organização deve demonstrar que as metas de uma área de processo estão sendo atingidas. Isso é feito identificando-se a evidência de práticas. Entretanto, as práticas não precisam ser as descritas na especificação CMMI. A organização é livre para propor práticas alternativas e evidência apropriada.

O avaliador deve então estar de acordo que isto seja apropriado para demonstrar a meta. Isso fornece um designer de processo com uma grande quantidade de liberdade.

Conforme se concentra, o MSF para Aprimoramento do processo CMMI não requer quaisquer práticas alternativas com a exceção da prática e evidência para a prática específica REQM 1.4, que solicita uma completa rastreabilidade de ponta-a-ponta de artefatos. Isso poderia ser considerado oneroso para muitos projetos ágeis. A razão pela qual as práticas alternativas não eram requeridas tem mais a ver com a interpretação da intenção. Quando uma prática solicita que um plano seja feito e outra um comprometimento com programação, orçamento e especificação, há freqüentemente a suposição de que esses comprometimentos devem ser precisos – que há uma filosofia subjacente de conformidade ao plano e à especificação. Quando outra prática solicita uma revisão do planejado versus real e a criação de um relatório detalhando o desvio da especificação, há a suposição de que é para auditar a qualidade como conformidade à especificação – qualquer desvio sendo uma falha na qualidade. Embora seja um entendimento comum em muitas organizações que praticam o CMMI, é preciso que seja verdadeiro. É aceitável documentar a abordagem como conformidade ao processo e os mecanismos de mensuração para serem conscientes da variação e definidos dentro de limites de variação de causa comum. Essa é a chave que destranca a possibilidade de uma implementação CMMI realmente ágil em todo o ciclo de vida.

Então, os planos e as especificações não precisam definir números e datas precisos, mas devem definir uma variação de números e datas aceitáveis. Enquanto esse é o entendimento organizacional comunicado e aceitável ao cliente, então é aceitável dentro do esquema de especificação e avaliação do CMMI. Por exemplo, um plano, baseado em dados de velocidade histórica de 1,7 cenário por desenvolvedor por semana com uma variação de poucos recursos de 0,8 e de alta capacidade de 2,5, deve oferecer conservadoramente o desenvolvimento de 80 cenários em 10 semanas, com 10 desenvolvedores, e definir uma meta expandida de 250 cenários. Um plano levemente mais agressivo poderia utilizar 8 semanas com um buffer de 2 semanas para variação e oferta de um mínimo de 8 x 17 = 136, com a mesma meta expandida de 250.

Gerenciamento de velocidade e fila

No nível mais alto de maturidade, o CMMI necessita de aprimoramento contínuo executado sob condições de controle objetivo. É recomendado que isso seja alcançado com uso de controle estatístico do modo promovido por Deming em sua Teoria de Conhecimento Profundo. Era desejável para nós entregar um método que correspondesse ao CMMI nível 3, mas preparasse o terreno para uma futura versão que poderia conduzir totalmente nossos clientes ao nível 5. O SEI acredita firmemente que os benefícios econômicos do CMMI são gerados em níveis de maturidade mais altos. Na Microsoft, acreditamos que nossos clientes desejarão essencialmente fazer a transição para o nível 5 e quisemos facilitar isso com um caminho incremental tranqüilo, utilizando nosso modelo existente de processo. Era, portanto, necessário considerar o nível 5 em nosso planejamento e, ao mesmo tempo, manter o foco na geração de uma solução de nível 3.

Se devemos seguir uma abordagem de Deming para atingir o nível 5 do CMMI, deve haver um mecanismo que permita a monitoria do controle estatístico. A compatibilidade com métodos ágeis pode ser alcançada pela mensuração da velocidade de produção dos itens valorizados pelo cliente e pela utilização dessa métrica no planejamento. No MSF, os itens de valor são definidos como cenários de utilização [Carroll 2000]. Os cenários não devem ser confundidos com casos de uso ou caminhos via casos de uso. Lá a herança é bem diferente e nascida do campo de engenharia da usabilidade. Os cenários são descrições concretas de utilização que não tentam adivinhar a implementação de sistemas subjacentes. No MSF, os cenários, como os requisitos do cliente, são analisados e decompostos em tarefas de arquitetura, desenvolvimento, teste e experiência do usuário. A Figura 1 mostra a velocidade de conclusão da tarefa (ou o índice de produção do processo). Isso é muito diferente da abordagem mais tradicional de gerenciamento de projetos de estimar o tempo de cada tarefa e então acompanhar o desempenho planejado versus real. O último simplesmente mensura a variação na estimativa da habilidade ou falta de conformidade com o compromisso local individual, enquanto o primeiro mensura a variação em todo o sistema da produção de valor ao cliente.

Figura 1. Velocidade de conclusão (ou índice de produção) em um gráfico de controle XMR

A mensuração da velocidade não é suficiente por si só para identificar variação de causa especial no processo. Shewart chamou as causas especiais de “causas atribuíveis”. Em outras palavras, deve haver um evento atribuível específico que possa ser identificado como a causa raiz. Um registro de problemas do projeto é uma boa fonte para a identificação da variação de causa especial. O registro de problemas está armazenando o histórico de solicitações da engenharia por ajuda. Por implicação, as solicitações de ajuda indicam variação potencial ou real de causa especial. Poderia ser o caso em que uma causa especial não seria identificada inicialmente e ficaria invisível. O gerenciamento pode optar por investigar ou simplesmente minimizá-la como inexplicada. Organizações claramente mais maduras são melhores nesta investigação da causa raiz e mostram que os processos estão sob maior controle.

Podemos acompanhar bloqueios no WIP (Trabalho em andamento) monitorando o enfileiramento do trabalho para processamento. David Anderson [2003] mostrou como fazer isso utilizando fluxogramas cumulativos [Figura 2] com base no trabalho de Reinertsen [1997]. O monitoramento do nível WIP com uso de controle estatístico [Figura 3] permite várias coisas. Os níveis WIP predizem o tempo de produção e, portanto, a futura influência no cronograma do projeto. Os níveis de WIP podem também indicar o bloqueio de itens de trabalho e onde no ciclo de vida o bloqueio está ocorrendo.

Deming sugeriu que havia apenas 2 tipos de erro que um gerente poderia cometer. Ele os chamou de Erro nº. 1 e Erro nº. 2. O Erro nº. 1 está interferindo quando tudo está normal — quando o processo mostra controle estatístico. Ele chamou isso de adulteração. Quando um processo está sob controle, deveria ser deixado em paz. Os microgerentes têm uma tendência a adulterar, pois reagem a flutuações sem considerar o quadro maior. Portanto, o microgerenciamento geralmente conduz ao erro nº. 1. Quando um processo está sob controle, deve-se permitir que os trabalhadores se auto-organizem sem a intervenção do gerenciamento. Esse conceito soa muito ágil. O Erro nº. 2 é uma falha ao intervir quando um processo está fora de controle. Um processo fica fora de controle quando algo externo o afeta. Em linguagem comum, chamamos isso de problemas. Quando um problema está bloqueando o fluxo de valor em um processo de desenvolvimento de software ágil, todos entendem que alguém (normalmente um gerente de projeto) deve ser designado para eliminá-lo. Métodos como o Scrum [Schwaber 2001] tornam isso muito explícito. Evitar o erro nº. 2 tem a ver com o gerenciamento agressivo de problemas e bom gerenciamento de riscos. Um risco, afinal de contas, é simplesmente um problema que ainda não aconteceu!

O registro de problemas deve refletir as tendências no WIP. O registro de problemas deve conter detalhes das causas atribuíveis para variações de causa especial.

O registro de problemas e WIP bloqueado podem ser utilizados para avaliar a capacidade da organização em eliminar a variação de causa especial. A Figura 4 mostra o fluxo cumulativo de problemas no registro de problemas. Os gerentes de projeto trabalharão para resolver problemas e encerrá-los. Ocasionalmente, os problemas não serão encerrados rápido o suficiente, resultando em trabalho em andamento bloqueado no registro posterior do projeto (ou interação) principal. Isso é mostrado no gráfico de linhas sobrepostas. Uma falta de bloqueio de trabalho indicaria uma falta de variação de causa especial, enquanto o inventário WIP e os gráficos de Velocidade de conclusão mostram a extensão da variação de causa comum.

Um entendimento da variação de causa comum pode ser utilizado para o planejamento e avaliação do projeto. Um entendimento do risco associado à variação de causa especial pode ser utilizado para calçar o plano de projeto com buffers (efetivamente, garantia) contra deslizes da programação ou geração de funcionalidade reduzida, devido ao deslize de velocidade.

Planejamento iterativo e adaptável

Ao definir um conjunto de métricas ágeis, mas construindo-as dentro de uma estrutura de controle estatístico, preparamos o terreno para um método ágil comparável ao CMMI nível 5. O que é necessário agora é um mecanismo de planejamento iterativo e adaptável que possa ser reconhecido como ágil.

A solução é fornecer um plano de projeto flexível, que se aproxime do escopo de um projeto completo e defina um plano para uma série de interações que definem aproximadamente o que será desenvolvido em cada uma. O segredo é evitar o grande planejamento antecipado. Alcançamos isso definindo uma pequena série de cenários de ponta-a-ponta CTQ (Críticos para qualidade) e esboçando cada um. Como definido anteriormente, a qualidade é definida pelo cliente. É importante obter o quanto antes, mesmo que aproximado, um entendimento mútuo disso. O cliente deve concordar que esses cenários CTQ representam a ampla intenção do produto ou serviço idealizado como o resultado de um projeto. Os CTQs são então atribuídos em relação a interações no plano de projeto. Então, o plano de projeto é muito flexível e aproximado, embora detalhado o suficiente para comunicar ao cliente a essência do que obterão em cada estágio do projeto. É importante que o cliente comunique o que representa uma cadência adequada de interações a partir de sua perspectiva. É provável que o ciclo comercial natural dite como o cliente deve absorver nova funcionalidade e perceber o seu valor. Então, o cliente determinará o comprimento da interação. Um compromisso para um plano de projeto é, portanto, possível a partir de todas as partes interessadas. Esse compromisso é parte crítica dos requisitos do CMMI.

O planejamento detalhado é então deixado para o início de uma interação, em que um conjunto de cenários detalhados e específicos ganha corpo ao redor dos cenários CTQ previamente identificados. Os testes de aceitação são escritos para cada cenário e, juntos, requisitos e testes formam o escopo do plano de interação. Os cenários são classificados utilizando as regras MoSCoW [DSDM 2005]. A métrica para a velocidade e a variação é utilizada para determinar um nível mínimo de produção para a interação, com base na extremidade inferior do intervalo de capacidade, e uma meta de expansão baseada na extremidade superior é determinada. Requisitos do tipo “deve ter” são atribuídos em relação ao nível mínimo e requisitos “deveria ter” ou “poderia ter” em relação à meta de expansão. O plano então é acordado por todas as partes interessadas e os comprometimentos são feitos.

Durante a interação, solicita-se que os engenheiros continuem a se concentrar na conformidade ao processo, utilizando os relatórios de fluxo de velocidade e cumulativos junto com o registro de problemas e relatório de WIP bloqueado. A variação na velocidade será um item que requer atenção. Uma estimativa precisa do escopo que será realmente produzido pode ser feita diariamente. Deveria continuar a permanecer dentro dos limites do nível mínimo e da meta de expansão ou deveria haver uma causa atribuível para explicar por que não. A atenção do gerenciamento pode então ser focalizada em tais problemas e as ações de recuperação iniciadas. Ao fazer isso, os requisitos para a análise de causa raiz e ação corretiva no CMMI são abordados.

Novamente, mesmo no nível de interação, o planejamento permanece flexível. O plano para uma interação contém apenas um registro posterior classificado em requisitos do tipo “deve ter”, que compõem o nível de comprometimento mínimo, e outros que representam um buffer para a variação natural no método de desenvolvimento de software sendo utilizado. A equipe tem autonomia para se auto-organizar dentro de uma interação. O plano é calculado com uso de médias obtidas de dados históricos. Quando não houver histórico disponível o plano deve ser baseado em uma melhor suposição e monitorado freqüentemente com uso dos relatórios mostrados nas figuras 1 a 4. O plano pode ser ajustado de acordo. Isso afeta apenas a primeira interação de um novo projeto com uma nova equipe.

Expandindo o MSF para Desenvolvimento de software Ágil

O MSF para Desenvolvimento de software Ágil correspondeu à intenção básica do CMMI, mas houve falta de alguma formalidade e orientação específica para algumas áreas do processo. Em muitos métodos de desenvolvimento ágil, muito da infra-estrutura para desenvolvimento de confiabilidade de software está implícito ou deixado para resolução por meio de um método de gerenciamento de problemas de propósito geral. Por exemplo, se a falta de um ambiente de gerenciamento de configuração é um problema de bloqueio, então a resolução seria colocar um em vigor. O CMMI, baseado em décadas de experiência de engenharia de software, já inclui muitos desses aspectos. A criação de ambientes adequados, o comissionamento de ferramentas apropriadas, a iniciação de projetos com visão suficiente, a comunicação dessa visão com eventos de lançamento e planejamento para a percepção de valor por meio de desenvolvimento são todos parte da prescrição do CMMI.

Não há nada particularmente em conflito com a filosofia ágil nessas coisas. A principal diferença é que são explicados explicitamente.

Era, portanto, necessário aprimorar o MSF para o Desenvolvimento de software Ágil com atividades adicionais para cobrir esses aspectos do CMMI.

Isso não era trivial. A área do material de orientação para o MSF para o Aprimoramento de processo CMMI é 150% maior que a do MSF para Desenvolvimento de software Ágil. Assim, grande quantidade de expansão foi necessária. Por exemplo, o MSF para Desenvolvimento de software Ágil tinha 25 objetos de produto de trabalho enquanto o método CMMI tinha 59. Havia 9 gráficos de métricas com o método ágil, enquanto o método CMMI tinha 12. Entretanto, uma típica implementação do processo CMMI tinha mais de 400 objetos [Ahern 2005]. Uma combinação de ferramentas integradas e uma abordagem ágil geral para o projeto do processo reduziu a sobrecarga – o peso – no processo em cerca de 85%.

O resultado é um modelo de processo maior do que um típico processo ágil com levemente mais formalidade com respeito a aprovações, assinaturas e auditorias, mas que tem um núcleo ágil e adaptável, e é leve em comparação a uma tradicional abordagem CMMI. Acreditamos que o MSF para Aprimoramento do processo CMMI representa uma metodologia ágil altamente produtiva, que inclui um mecanismo formal de qualidade e encoraja uma cultura de aprimoramento contínuo.

Conclusões

As implementações do processo CMMI estão freqüentemente associadas à conformidade ao plano, a ambientes de baixa confiança e a estruturas de comando e controle. Elas requerem uma grande abordagem de projeto antecipado com auditoria de conformidade e implicações de punição por não conformidade. Isso gera medo, e o medo encoraja maior foco em planejamento conjunto mais detalhado, com disposição cega para seguir tal plano. Como resultado, as necessidades do cliente tornam-se desconectadas do trabalho e a alteração orientada pelo cliente torna-se inaceitável, pois a alteração deve estar refletida no plano para que o resultado esteja em conformidade com o plano. O efeito é uma grande quantidade de retrabalho adicional sem valor.

Este documento mostra que é errado associar esses comportamentos de engenharia de software indesejáveis ao CMMI. Não tem de ser dessa maneira.

Ao adotar os ensinamentos de W. Edwards Deming e entendendo sua relação com princípios e práticas ágeis, é possível desenvolver um processo de ciclo de vida completo realmente ágil, que corresponda aos requisitos para todos os 5 níveis no modelo CMMI. Especificamente por utilizar métricas ágeis, como velocidade, fluxo cumulativo e tendências em questões abertas, concebemos os métodos de planejamento e monitoramento que adotam a variação e permitem comprometimento postergado e tardio e planejamento iterativo adaptável.

Fazendo assim, o processo adota as idéias do manifesto ágil [Cunningham 2001], como valorizar a colaboração do cliente acima da negociação do contrato e responder à mudança acima de seguir um plano. Ao adotar a variação e aceitá-la como parte de um processo centralizado no humano, abrangem-se indivíduos e interações acima de processos e ferramentas. E, finalmente, pelo uso de ciclos iterativos, acordados em uma cadência aceitável para o cliente, gera-se software em funcionamento acima de documentação abrangente.

Fonte: MSDN

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Introdução ao Microsoft Solution Framework – MSF e ao Agile

Augusto Vespermann — Fri, 09 Apr 2010 11:09:24 +0000

Number of View: 563

A MSF foi criado em 1994, e originou-se da análise de times de projetos e grupo de produtos, estas análises eram constatadas com a indústria de práticas e métodos. Estes resultados combinados eram consolidados em melhores praticas entre pessoas e processos.

O MSF (Microsoft Solutions Framework) tem sido usado pela Microsoft como o seu “método” para desenvolvimento de soluções de software dentro da Microsoft e também para os milhares de clientes e parceiros da Microsoft em todo o mundo.

A disseminação deste método, agora na versão 5.0, normalmente induz as pessoas a compará-lo com outros “métodos” da indústria, como o RUP, CMMI ou XP, entre outros. É importante entender, entretanto, o que são estes elementos antes de compará-los.

O MSF para Desenvolvimento Ágil de Software é um guia de procedimentos, uma coleção de boas práticas para projetos de desenvolvimento de softwares.

Um projeto MSF é regido por ciclos ou iterações. A cada ciclo, cada componente da equipe executa suas funções e atualiza o resultado do seu trabalho conforme a necessidade. Os ciclos se repetem até que o projeto seja concluído ou cada versão seja lançada.

Cada componente da equipe será responsável por um ou mais papéis, dependendo do tamanho ou da complexidade do projeto.

A Microsoft não classifica o MSF como uma metodologia, mas sim como uma disciplina. O que isso quer dizer? Basicamente que o MSF serve como um grande guia e uma coleção de boas práticas. Porém, o MSF não se aprofunda em detalhes.

Por exemplo, em um dado momento do projeto, o MSF diz que você terá que fazer uma especificação funcional.

Entretanto, ele não define se você deve usar UML, análise essencial ou outras técnicas. Isso fica a seu critério.

A falta de detalhes do MSF pode parecer uma deficiência a princípio, mas essa característica permitiu uma abordagem simples e direta das técnicas apresentadas. Ou seja, o MSF permite uma fácil compreensão tanto por parte da equipe como do cliente, além de ser bastante flexível em sua aplicação.
PRINCÍPIOS DA MSF
Foco no negócio: Entender porque o projeto existe da perspectiva do negócio e como este valor é medido.
Comunicação: MSF aconselha a comunicação aberta em toda a equipe, clientes e outros componentes do time.
Visão de projeto compartilhado: O processo de compartilhamento de visão de projeto é especificado no início do projeto. Na criação desta visão o time se comunica no intuito de identificar e resolver conflitos e resolver visões enganosas. Isto permite definir a direção do projeto.
Esclarecer as responsabilidades compartilhadas: Todo o time compartilha várias responsabilidades para ensinar ao time e seu relacionamento aos respectivos stakeholders.
Mais poderes aos membros do time: Baseado em time de pares MSF dá poderes aos membros do time por ter que atingir as metas e entregas, aceitando o fato de terem as responsabilidades compartilhadas por tomar decisões, direções quando necessário.
Agilidade: As iterações do ciclo de vida do modelo de processo habilitam ajustes de cursos para a entrega do projeto em cada milestone.
Investimento em qualidade: MSF tem por premissa que todo o time é responsável por balancear os custos, e funcionalidades para preservar a solução em qualidade e assegurar a qualidade. Membros do time precisam construir qualidade em todas as fases até o sucesso da solução, e por sua vez a organização deve investir em seu time em educação, treinamento, e experiência.
Aprender com todas as experiências: Nos últimos 20 anos houve um crescimento colossal no que diz respeito à taxa de sucesso de projetos. Dados que a maior causa de falha são praticamente os mesmos, as organizações de TI não aprendem com as suas falhas de projeto. O MSF engloba o conceito de contínuo crescimento baseado em aprendizado individual e de time.

GERENCIAMENTO DE PREPARAÇÃO
No início de um projeto da solução, antes da fase de visão/escopo, a organização precisa ter um claro entendimento destes aspectos:
Seu cenário e requisitos de segurança específicos: para atender às necessidades das organizações que iniciam implementações de soluções de segurança, o Microsoft Solutions for Security (MSS) criou o SRMG. O SRMG é um processo detalhado usado para determinar quais ameaças e vulnerabilidades têm o maior impacto potencial em uma determinada organização. Como cada empresa tem requisitos comerciais diferentes, é impossível criar uma lista de vulnerabilidades que tenham o mesmo impacto em todos os ambientes. Por isso, o SRMG permite que uma organização aumente de forma incremental sua segurança e identifique áreas potenciais que precisam de correção no futuro.
Suas competências internas: o objetivo desta solução é ser facilmente entendida e imediatamente implementada por um Microsoft Certified Systems Engineer (MCSE) com boa experiência e pelo menos uma familiaridade básica com os materiais do Microsoft Official Curriculum (MOC).

MODELOS MSF: TIME E PROCESSOS
Modelo de Time (Team Model) habilita a escalabilidade do projeto, identifica quem vai trabalhar durante o projeto e linca cada time com um responsável Modelo de Processo (Process Model) provê a alta qualidade através do ciclo de vida do projeto (Disciplina de Gerência de Riscos; Disciplina de Gerência de Projetos). O process model trabalha em conjunto com o Team Model organizando o processo em fases distintas criação, teste, publicação.
MSF VERSÂO 4.0
A Microsoft Solution Framework versão 4.0 é uma combinação de um metamodelo, que pode ser usado como base para processos de engenharia de software prescritivo, e dois personalizável e escalável processos de engenharia de software. Os MSF metamodelo consiste de princípios fundamentais, uma equipa modelo e ciclos e iterações.
MSF 4.0 fornece uma ferramenta de alto nível quadro de orientações e princípios que podem ser mapeados para uma variedade de modelos prescritivos processo. O programa está estruturado em duas metodologias descritivas e prescritivas. A componente descritiva é chamado a MSF 4,0 metamodelo, que é uma descrição teórica do SDLC melhores práticas para a criação de metodologias SDLC. Microsoft é da opinião de que as organizações têm diferentes dinâmicas e contrariando as suas prioridades durante o desenvolvimento de software; algumas organizações necessitam de uma sensível e softwares adaptáveis ambiente de desenvolvimento, enquanto outros precisam de uma padronizado, repetitivo e mais ambiente controlado. Para atender estas necessidades, a Microsoft representa o metamodelo de 4,0 MSF em dois modelos que prevêem prescritivo metodologia específica processo de orientação, chamado Microsoft Solutions Framework para Agile Software Development (MSF4ASD) e Microsoft Solutions Framework para Capability Maturity Model Integration Melhoria de Processos (MSF4CMMI). Note-se que estes processos de engenharia de software podem ser modificados e personalizados de acordo com as preferências da organização, clientes e equipe do projeto.
A filosofia MSF afirma que não existe uma única estrutura ou processo que se aplica optimamente os requisitos e ambientes para todos os tipos de projetos. MSF, portanto, suporta múltiplas abordagens processo, para que possa ser adaptado para apoiar qualquer projecto, independentemente da sua dimensão ou complexidade. Esta flexibilidade significa que ele pode oferecer suporte a uma ampla variação no grau de execução dos processos de engenharia de software, mantendo porém a um conjunto de princípios fundamentais e mentalidades.

A Microsoft Solutions Framework Process Model consiste em séries curtas de ciclos de desenvolvimento e iterações. Este modelo abraça iterativo rápido desenvolvimento com a aprendizagem contínua e refinamento, devido ao progressivo conhecimento da empresa e do projeto de todos os agentes envolvidos. Identificar necessidades, desenvolvimento de produtos, e os ensaios ocorrem nas sobreposições iterações, resultando em acréscimo conclusão de assegurar um fluxo de valor do projecto. Cada iteração tem um foco diferente eo resultado é uma porção estável do sistema global.

Seguem-se os oito princípios fundamentais, que constituem a espinha dorsal para os outros modelos e disciplinas do MSF:

1. comunicação aberta

2. Trabalhar em prol de uma visão compartilhada

3. Capacitar os membros da equipa

4. Estabelecer uma responsabilidade clara e partilhada

5. Concentre-se em negócio prestação valor

6. Fique ágil, esperam mudanças

7. Invista na qualidade

8. Aprenda com todas as experiências

MSF Models

MSF consiste de dois modelos:

1. MSF equipe modelo. Este artigo descreve o papel dos vários membros da equipe de projeto de desenvolvimento de software. Os membros dessa equipe seria:

Gerente de Produto: Principalmente lida com clientes e definir requisitos projecto, garante ainda a cliente as expectativas são cumpridas.
Gestão de Programas: Mantém projeto desenvolvimento e entrega ao cliente

Arquitectura: Responsável pela concepção solução, garantindo a solução óptima concepção satisfaz todas as necessidades e expectativas

Desenvolvimento: Desenvolve de acordo com as especificações.
Teste: Ensaios e garante a qualidade dos produtos
Lançamento / Operações: Garante a implantação eo bom funcionamento do software
Experiência do Usuário: Apoia questões dos usuários.

Uma pessoa pode ser atribuído a desempenhar múltiplos papéis. MSF também tem sugestão sobre como combinar a responsabilidades, como o dono da obra não deve ser atribuída a qualquer outro papel.

2. MSF modelo de governação. Esta descreve as diferentes fases da transformação de um projeto. O Modelo de Governança MSF tem cinco faixas sobreposição de actividade (ver abaixo), cada um com uma meta de qualidade definidos. Essas faixas de atividade definir o que precisa ser cumprida e deixar como eles se realizem para a equipa seleccionada metodologia. Por exemplo, as faixas podem ser pequenos e realizada no âmbito rapidamente para ser coerente com uma metodologia Agile, ou pode ser serializada e alongada para ser coerente com uma metodologia Cachoeira.

Envision – pense sobre o que deve ser realizado e identificar constrangimentos
Plano – planejar e projetar uma solução para atender as necessidades e expectativas dentro dessas limitações
Build – construir a solução
Estabilizar – validar a solução que vá ao encontro das necessidades e expectativas
Implantar – implantar a solução

MSF Project Management Process

Integrar planejamento e condução mudança de controlo
Definir e gerenciar o escopo do projeto
Preparar um orçamento e gerenciar os custos
Preparar e acompanhar os horários
Garantir que os recursos são atribuídos à direita do projecto
Gerir contratos e vendedores projeto e adquirir recursos
Facilitar a equipe e comunicações externas
Facilitar o processo de gestão do risco
Documento e monitorar a qualidade da equipe do processo de gestão

MSF para Agile Software Development metodologia

O MSF para Agile Software Development (MSF4ASD) se destina a ser um peso leve, processo iterativo e adaptável.

O MSF4ASD usa os princípios do desenvolvimento ágil abordagem formulada pela Agile Alliance. O MSF4ASD prevê um processo de orientação que incide sobre as pessoas e as mudanças. Inclui aprendizagem de oportunidades e de avaliações usando iterações em cada iteração.

MSF para Capability Maturity Model Integration metodologia Melhoria de Processos

O MSF para Capability Maturity Model Integration Melhoria de Processos (MSF4CMMI) dispõe de mais artefatos, mais processos, mais signoffs, mais planejamento e destina-se a projectos que requerem um maior grau de formalidade e cerimônia.

O MSF4 CMMI é uma metodologia formal para a engenharia de software. Capability Maturity Model foi criada a partir do Software Engineering Institute da Universidade Carnegie Mellon, e é um processo de melhoria abordagem que fornece às organizações com os elementos essenciais do processo de melhoria contínua, resultando em uma redução SDLC, a melhoria da capacidade de cumprir as metas custo e cronograma, materiais de construção de alta qualidade. O MSF4CMMI que ampliou o MSF4ASD orientação adicional com formalidade, comentários, verificação e de auditoria. Isso resulta em um processo que depende do SEP e ao processo e não conformidades confiando unicamente na confiança e na capacidade de cada um dos membros da equipe. O MSF4CMMI tem mais documentos obrigatórios e relatórios do que a versão ágil, mais formal e desenvolvimento deste processo reduz risco em grandes projetos de software e fornece um estatuto mensuráveis. Uma das vantagens de utilizar o CMMI é o processo pelo qual uma avaliação padrão poderão comparar a capacidade de desenvolver software em outras organizações.

Fonte: Wikipedia

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Qualidade de software com CMMI

Augusto Vespermann — Thu, 08 Apr 2010 11:04:39 +0000

Number of View: 561

O modelo ®CMMI – Capability Maturity Model Integration – é um modelo de referência para melhoria de processos de desenvolvimento de software criado pelo Software Engineering Institute (SEI) da Carnegie Mellon University, situada em Pittsburgh – EUA. A versão 1.1 do modelo foi publicada em 2002, a partir dos antigos modelos CMM para disciplinas específicas e outros modelos de referência então existentes.

O modelo CMM foi concebido para atender a uma demanda do Departamento de Defesa Norte-Americano – DoD, que necessitava de um mecanismo objetivo para avaliar seus fornecedores de software. Entretanto, o CMM, e mais recentemente o ®CMMI, tornaram-se um padrão de mercado para mensurar a capacidade de entrega e a maturidade das empresas fornecedoras de software e serviços.

Atualmente, o ®CMMI é o modelo mais recomendado para empresas que pretendem exportar software ou serviços de TI, devido a sua ampla aceitação no mercado comprador internacional.

A versão atual do modelo – ®CMMI-DEV 1.2, publicada em 2006, possui 22 áreas de processo distribuídas em 4 níveis de maturidade. Além do modelo para desenvolvimento de software (DEV), foram publicados posteriormente os modelos de referencia para aquisição de software (ACQ) e para Serviços (SVC).

O ®CMMI é um modelo de referência muito difundido e utilizado por empresas nos cinco continentes. Em relatório de maturidade publicado pelo SEI em setembro de 2009, existiam aproximadamente 3,9 mil organizações formalmente avaliadas em algum nível de maturidade do CMMI. Os países com maior número de organizações avaliadas são: EUA, China, Índia, Japão e Espanha. O Brasil encontra-se no 9º lugar neste ranking, com um total de 117 organizações avaliadas.

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Visual Studio 2010 com o novo Framework 4.0 será lançado dia 12 de abril

Augusto Vespermann — Tue, 30 Mar 2010 11:22:36 +0000

Number of View: 5459

Foi definida pela Microsoft a data de lançamento do Visual Studio 2010 com o novo Framework 4.0. O lançamento deve ocorrer no dia 12 de abril de 2010.

Seguem algumas novidades do Visual Studio 2010 para que você já vá conhecendo um pouco melhor a ferramenta:

• Arquitetura & Design
- Ferramenta para criar e compartilhar vários tipos de diagramas como o caso de uso, atividade e diagramas de sequência.
-Ferramentas para modelagem que são fortemente integrados com o código que auxiliam na manutenção mantendo-os sincronizados.
• Arquitetura validações

- Verifica entrada de dados usando modelos de validação pré-existentes e faz validações no momento do check-ins e compilações.

• Architecture Layer Diagram

- Uma das ferramentas mais úteis e simples. Permite a representação da arquitetura em camadas mostrando as dependências entre elas. Também permite mapear componentes físicos como classes, namespaces, etc.
• OMG UML foi introduzido no Visual Studio 2010.
• Suporte para UML 2.1.1 – 5 de 13 diagramas – casos de uso, componente, atividade, classe e diagramas de sequência.
• Ferramenta para manter todos os diagramas UML sincronizados de forma que uma alteração de um reflete automaticamente no outro.
• UML é desenvolvido utilizando toolkit DSL.
• Será integrado ao Visio 1,1.
• Model Explorer – Similar ao Solution Explorer, isso permite que você explore todos os modelos que você criou que inclui objetos criados como parte de vários diagramas UML.
• Ferramenta para criar um diagrama de seqüência a partir do código existente, basta clicar com o botão direito no editor de código VS e selecionando “Gerar Diagrama de Seqüência …”
• Programação Paralela: para melhor utilizar o poder de multi-processamento de máquinas multi-core,. NET 4.0 irá adicionar suporte para programação paralela usando PLINQ, da Biblioteca de Tarefas paralelas e Coordenação de Estruturas de Dados. O depurador foi aprimorado para identificar problemas de concorrência. Dois novos recursos adicionados são MultiStack e vistas de um lista de tarefas. Introdução de relatório de análise de concorrência para análise de desempenho de aplicações.
• Qualidade / Teste
-Teste de Impacto – Identificar e executar apenas os testes que têm como escopo uma parte do código.
• A Microsoft Test Runner Tool – uma ferramenta autônoma que usa um testador para guiá-los através de uma série de passos para completar um caso de teste. Durante o ensaio, esta ferramenta pode gerar um ambiente de teste, screenshots e até mesmo aplicação de captura de vídeo completa para auxiliar na reprodução de bugs.
• Gerenciamento do Código Fonte
- Fluxo de trabalho: Recursos aprimorados de controle de versão, incluindo check-in, branch visualization e build workflow.
•Gerência de Projetos
• Integração com o Project Server para a empresa com grandes projetos e novos recursos para projetos ágeis.

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

O que é a Certificação PMP do PMI

Augusto Vespermann — Sun, 14 Mar 2010 13:45:12 +0000

Number of View: 12100

O que é a Certificação Project Management Professional (PMP®)?
O PMP é um rigoroso programa de certificação oferecido pelo Project Management Institute (PMI) como forma de capacitação profissional , visando o reconhecimento oficial e público de habilidades individuais no campo de Gerenciamento de Projetos e avanço da profissão.
A certificação PMP é a credencial profissional mais reconhecida e respeitada em termos mundiais no que tange ao Gerenciamento de Projetos. Em 1999, o PMI tornou-se a primeira organização no mundo a ter seu Programa de Certificação reconhecido pela International Organization for Standardization (ISO) 9001.

Quais os benefícios de se obter a Certificação Project Management Professional (PMP)?
- Ampliação da empregabilidade
- Reconhecimento do grau de qualificação atestado internacionalmente
- Aceleração do progresso profissional
- Qualidade e efetividade no gerenciamento dos projetos.

Quem pode obter a Certificação Project Management Professional (PMP)?
Para obter a Certificação PMP, o profissional deve satisfazer a determinados requisitos de educação e experiência, concordar e aderir ao Código de Conduta Profissional (Code of Professional Conduct) e passar no Exame de Certificação PMP. Para comprovação da experiência, existem duas categorias:

- Categoria I (candidatos com Bacharelado ou diploma equivalente): Experiência profissional mínima de três anos (36 meses), que contemple um mínimo de 4500 horas de trabalho na área de gerenciamento de projetos liderando e dirigindo atividades de projeto
O candidato deverá comprovar graduação através do diploma de conclusão de curso com grau de Bacharelado ou equivalente.
- Categoria II (candidatos sem grau de Bacharelado ou diploma equivalente): experiência mínima de cinco anos (60 meses), que contemple um mínimo de 7500 horas de trabalho na área de gerenciamento de projetos liderando e dirigindo atividades de projeto

Para ambas as categorias: comprovação de um mínimo de 35 horas de treinamento formal em gerenciamento de projetos. Além disto, em ambos os casos as horas de experiência deverão ter sido acumuladas nos últimos 8 (OITO) anos contados a partir da data de inscrição para o exame.

Quanto custa para fazer o exame de Certificação Project Management Professional (PMP®)?
-US$ 405,00 para filiados ao PMI;
-US$ 555,00 para não filiados
No formulário de inscrição para o exame o candidato deverá optar pela forma de pagamento.

Como tornar-se PMP?
O Processo de certificação é dividido em 2 fases:

1a. etapa – A habilitação
Para fazer o exame de certificação é necessário obter a – Carta de Elegibilidade – que certificará que o candidato possui os requisitos de educação e experiência desejados. Para tanto, é necessário:
- Preencher os formulários “Online Application for Certification Examination” (Online Application), “PMP Certification Examination Application”, “Project Management Education Form”, “Project Management Experience Verification Form”, que podem ser obtidos em PMP® Certification Handbook.

2a. etapa – O exame
Uma vez habilitado, o candidato receberá via e-mail uma carta do PMI (Elegibility Letter), informando detalhadamente como fará o exame, políticas de cancelamento/adiamento, e número do voucher, autorizando-o a fazer o exame de certificação e indicando condições para agendamento do exame.
O candidato, então, entra em contato com o centro de testes de sua escolha e marca a data da prova, informando o número do voucher. Os exames são agendados em centros Prometric. No Espírito Santo não existem centros Prometric credenciados que aplicam o exame PMP

O exame
O exame é composto de 200 questões (175 válidas para o exame, e 25 questões de validação) distribuídas aleatoriamente entre os cinco grupos de processos do PMBOK, acrescidos de “Responsabilidade Profissional”. Estatisticamente é adotada a seguinte distribuição para as questões:
* Iniciação – 11%
* Planejamento – 23%
* Execução – 27%
* Monitoramento e Controle – 21%
* Encerramento – 9%
* Responsabilidade Profissional – 9%.

O idioma principal do exame é o Inglês, sendo possível selecionar o Português como segunda língua, no
agendamento do exame.
O exame tem duração de 4 horas e é realizado via computador e o resultado é emitido ao término do exame. Serão qualificados aqueles que acertarem um mínimo de 106 das 175 questões válidas, o correspondente a 60,57% do total.
Os profissionais que não passarem no exame poderão enviar para o PMI um formulário para refazer o exame (Re-examination Form) até um ano após o último exame realizado.

Onde posso obter mais informações sobre o processo de Certificação PMP?
No site do PMI® (www.pmi.org) você encontra informações detalhadas sobre:
-Visão Geral da Certificação (PMP Handbook)
-Código de Conduta Profissional PMP® (PMP® Code of Professional Conduct)
-Inscrição online para o Exame de Certificação PMP® (Online Application Form)
-Dicas de Preparação da Inscrição para Certificação PMP® (Application Checklist)
-Dicas para se Preparar para o Exame de Certificação PMP® (Preparation of your Application)
-Locais de Realização dos Exames (Examination Locations)
-Informações sobre nova realização do exame (Re-examination Information)

(*) O PMI-ES trabalhará para manter este roteiro sempre atualizado, mas em caso de conflito entre as informações aqui contidas e as constantes do site do PMI (www.pmi.org), prevalecem as informações do site do PMI.

Fonte: PMI-ES

Posted from Vila Velha, Espírito Santo, Brazil.

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Visual Studio Team Foundation Server

Augusto Vespermann — Sat, 13 Mar 2010 13:00:39 +0000

Number of View: 5723

O Team Foundation Server talvez seja o conjunto mais significativo de recursos fornecidos pelo Team System. O Team Foundation ajuda a facilitar o trabalho de toda a equipe, fornecendo um novo sistema de gerenciamento de controle de origem, capacidades de controle de item de trabalho, automação de compilação, análise integrada e relatórios e um site de projeto colaborativo integrado. Ele também proporciona capacidades de gerência de projeto com a integração entre o Microsoft Project e o Microsoft Excel 2003.

Gerenciamento de controle de origem

O Microsoft Visual SourceSafe (VSS) é um dos sistemas de controle de código-fonte mais comuns para os desenvolvedores Microsoft e tem desempenhado um amplo e importante papel para os desenvolvedores de software ao longo dos anos. Entretanto, o VSS não ficou conhecido por sua escalabilidade, estabilidade, robustez ou capacidade de trabalhar bem com fusos horários e na Internet. O Visual Studio Team Foundation agora vem com um mecanismo de controle de origem inteiramente novo que soluciona todos esses problemas. Os componentes do servidor de controle de origem do Team Foundation utilizam o Microsoft SQL Server 2005 e representam uma solução de controle de origem escalável e bem arquitetada que funciona bem em HTTP e HTTPS, oferecendo suporte a outros recursos, como reconhecimento de fuso horário, que o ajudará a facilitar o desenvolvimento em vários locais geográficos, como aquele que é necessário para as equipes de desenvolvimento no exterior. A solução de controle de origem do Team Foundation também exerce um importante papel no processo de desenvolvimento de software, pois oferece suporte a diretivas de check-in, que são regras que governam o processo de check-in. Por exemplo, você pode exigir que os desenvolvedores associem um check-in a pelo menos um item de trabalho antes do processo de check-in, ajudando a estabelecer o rastreamento entre os itens de trabalho e o trabalho de desenvolvimento efetivamente concluído. Você também pode criar diretivas de check-in exigindo a execução da análise de código, ou até mesmo a execução de todos os testes de unidade antes da ação de check-in. Se um desenvolvedor precisar substituir essas diretivas, uma mensagem de email de notificação poderá ser enviada automaticamente aos membros adequados da equipe explicando a exceção. A Figura 11 e a Figura 12 demonstram como as diretivas e observações de check-in podem ser controladas pelos administradores de projeto.

Adicionando políticas de check-in

Adicionando observações de check-in

Outro recurso importante do controle de origem do Team Foundation são as prateleiras. As prateleiras permitem colocar seu código com check-out em um “conjunto de prateleiras” localizado no servidor, onde ele é mantido até que você esteja pronto para tirá-lo da prateleira. Essencialmente, isso permite que você armazene o código de trabalho em andamento em uma “prateleira” do servidor, sem sobregravar ou corromper o código existente na árvore viva. Isso é útil quando você precisa usar vários computadores, transferir trabalho parcialmente concluído para outro desenvolvedor ou alternar rapidamente para trabalhar em um problema de alta prioridade e, portanto, tirar suas alterações atuais do caminho.

Controle de item de trabalho

Como mencionado anteriormente, um item de trabalho é “algo” que pode ser atribuído e concluído por alguém de sua equipe. Em seu nível mais simples, ele poderia ser uma tarefa simples com uma transição de estado simples, como “aberto” e “fechado”. Entretanto, a maioria dos projetos tem tipos diferentes de itens de trabalho, cada um com suas próprias características, estados e transições de fluxo de trabalho. Outros exemplos de itens de trabalho incluiriam bugs, problemas, riscos ou mesmo recursos. Todos os itens de trabalho, independentemente de seu tipo, são armazenados no Team System. Quando você cria um projeto novo, a definição do projeto também determinará o número e tipo de itens de trabalho que você poderá criar. Cada tipo de item de trabalho pode ter seus próprios estados e transições e, em geral, cada item de trabalho pode ser atribuído a alguém, fornecendo informações como iteração alvo ou versão, prioridade etc. Os itens de trabalho também podem ser ligados a outros itens de trabalho, arquivos de controle de origem e mesmo um changeset dentro do controle de origem. A capacidade de vincular os itens de trabalho entre si e entre diferentes itens, como arquivos e código-fonte, oferece o rastreamento necessário em quase todos os projetos de desenvolvimento de software. Não se preocupe, este é um modelo bastante extensível e você pode fazer as alterações necessárias para oferecer suporte a necessidades específicas de seu projeto.

Exemplo de uso dos itens de trabalho para rastreamento

O Team System oferece um conjunto de itens de trabalho e você pode interagir com eles usando muitas ferramentas diferentes – desde o Microsoft Project, Microsoft Excel e Visual Studio até o Team Explorer – como mostram a Figura 14 e a Figura 15.

Definição de item de trabalho no Visual Studio (clique na imagem para ampliá-la)

Itens de trabalho no Excel (clique na imagem para ampliá-la)

Automação de compilação

A automação de compilação é uma prática recomendada de extrema importância para as equipes de desenvolvimento de software. O Team System oferece automação de compilação com o Team Foundation Build, que usa o MSBuild, pode executar testes da unidade associados e análise de código, libera compilações para um servidor de arquivos e publica relatórios de compilação para o restante da equipe. Os resultados e logs do Team Foundation Build podem ser propagados para o data warehouse do Team System para relatórios e análise. Além disso, o Team Foundation Build está totalmente integrado a outras ferramentas do Team System, como controle de origem e controle de item de trabalho.

Com o Team System, você pode ter muitos tipos diferentes de compilações que podem ser definidos e personalizados de acordo com suas próprias necessidades. Na verdade, o Team System oferece um assistente para iniciá-lo, como mostra a Figura 16.

Definindo um novo tipo de compilação

Os resultados de todas as compilações são mantidos e podem ser vistos dentro do Visual Studio ou por relatórios de compilações. Também é importante observar que você pode configurar muitos computadores de compilação para realmente executar o processo de compilação e pode disparar o processo de compilação por meio da GUI ou da linha de comando. Além disso, você pode configurar o Team System para notificá-lo sobre os resultados de uma compilação por email, como mostra a Figura 17.

Configurando alertas de eventos de compilação

Relatórios

Não seria ótimo se você pudesse gerar automaticamente um relatório que descrevesse a rapidez com que sua equipe está trabalhando todas as semanas, com base em suas atividades reais? Bem, adivinhe só! Com os recursos de relatórios do Team Foundation, você terá essa capacidade. O Team Foundation está incorporado ao SQL Server 2005 e armazena tudo sobre os itens de trabalho, atributos de qualidade, testes e resultados de testes, bem como resultados de compilação. Todas essas informações são agregadas com o SQL Server Analysis Services e ligadas aos recursos de relatório do Team System. Na verdade, os relatórios que o Team System oferece são criados com o SQL 2005 Reporting Services. Isso significa que você terá a capacidade de modificar os relatórios existentes e até mesmo criar seu próprio relatório de acordo com suas necessidades.

Muitos relatórios serão fornecidas com o Team System (um relatório de exemplo é descrito na Figura 18), porque eles fazem parte dos Team System Project Templates usados durante a criação dos novos Projetos do Team System. À medida que você personalizar o Team System Project Templates para criar seus próprios tipos de item de trabalho ou modificar as definições de itens de trabalho existentes, provavelmente desejará personalizar os relatórios padrão.

Figura 18. Exemplo de relatório (clique na imagem para ampliá-la)

Site de projeto

Ao criar um novo projeto do Team System, você deve criar um novo Microsoft Windows Sharepoint Site para ampliar ainda mais a colaboração do projeto. O Microsoft Windows Sharepoint Services oferece o gerenciamento de documentos e as capacidades de armazenamento da documentação criada pela equipe para o projeto. A definição do modelo de projeto do Team System também define a estrutura e o conteúdo do site do Sharepoint, imediatamente abaixo da estrutura da biblioteca de documentos e dos modelos de documento. Na verdade, você pode configurar o Team System para criar um site Project Portal com todos os artefatos que precisam ser preenchidos como parte de seu projeto, garantindo que o artefato correto seja entregue no momento certo.

O site Windows Sharepoint também conterá partes da Web que permitem visualizar os relatórios diretamente no site. Este é um recurso muito importante, porque agora os participantes não desenvolvedores do projeto sem o Visual Studio podem ir a um lugar para entender o estado geral, o status e os detalhes do seu projeto, diretamente em seus navegadores.

Site de projeto (clique na imagem para ampliá-la)

Gerência de projeto

Os gerentes de projeto em geral utilizam o Microsoft Project ou o Microsoft Excel para gerenciar “tarefas” que precisam ser feitas. No mundo do Team System, isso se traduz em poder gerenciar itens de trabalho de diversos tipos em toda a sua equipe. O Visual Studio Team System oferece uma interface interna que permite aos gerentes de projeto interagirem com os itens de trabalho. No entanto, em muitos casos, é bem mais natural fazer com que os gerentes de projeto usem as ferramentas que mais utilizam para realizar seus trabalhos. Por esse motivo, o Team System permite sincronizar os itens de trabalho com o Microsoft Excel e o Microsoft Project. Nessas ferramentas, os gerentes de projeto estão livres para atribuir e controlar todos os itens de trabalho (seja qual for o tipo) de forma natural e produtiva.

Os relatórios também são extremamente importantes para os gerentes de projeto. Com o Team System, eles poderão utilizar os diversos relatórios internos fornecidos com o produto, e também as ferramentas de análise como o Microsoft Excel para fazer a conexão com o data warehouse do Team System e analisar os dados do projeto. Os gerentes de projeto também podem usar os recursos do site do Windows Sharepoint criados para cada projeto do Team System, para facilitar a comunicação e gerenciar todos os documentos e artefatos do projeto.

Extensão e personalização do Team System

Como já foi mencionado, o Team System não é apenas um conjunto de ferramentas: ele é uma plataforma. Não quero realmente passar muito tempo discutindo extensão, além de listar as áreas que podem ser estendidas pelo Team System. A tabela a seguir oferece uma visão geral dessas opções.

Resumo da extensão do Team System

Área de personalização	Descrição
Modelos de projeto	Um modelo de projeto do Team System é usado durante a criação de um novo projeto do Team System e define todos os aspectos do projeto, incluindo relatórios, definições de item de trabalho, diretivas de controle de origem, estrutura e conteúdo do Windows Sharepoint Services, orientação de processo e permissões. Você pode definir seus próprios modelos de projeto de acordo com as necessidades organizacionais ou de projeto. Observe que não há ferramentas incorporadas no Team System para personalizar esses modelos e, assim, eles devem ser modificados com seu editor XML preferido.
Itens de trabalho	Você pode definir seus próprios itens de trabalho ou personalizar itens de trabalho existentes – usando novamente seu editor XML preferido.
Controle de origem	Para cada projeto do Team System você pode definir as diretivas de controle de origem e os campos de notas de check-in.
Tipos de compilação	Você pode definir seus próprios tipos de compilação dentro do Visual Studio Team System.
Site do Windows SharePoint Services	Você pode modificar os documentos contidos no site do Windows Sharepoint, além de usar os recursos de personalização do Windows Sharepoint Services para ajudar a promover maior colaboração entre a equipe.
Relatórios	Você pode modificar os relatórios existentes ou criar relatórios novos usando o SQL 2005 Reporting Services, que aproveita as informações armazenadas no data warehouse do Team System.
Kit de ferramentas de extensão	Você pode baixar o kit de ferramentas do Visual Studio Team System para obter informações detalhadas sobre as opções de extensão. Esse kit de ferramentas também demonstra como criar seus próprios tipos de teste e como explorar o modelo de objeto Team System para obter opções de personalização mais extensas.

Posted from Vila Velha, Espírito Santo, Brazil.

Rating: 0.0/10 (0 votes cast)

Compartilhe:

Posts Relacionados

Conhecendo o Scrum: metodologia ágil de desenvolvimento de software

Augusto Vespermann — Thu, 11 Mar 2010 11:52:30 +0000

Number of View: 12777

Estudando o Microsoft Visual Studio Team System 2008 vi que podemos implementar várias metodologias de Gerência de Projetos configuráveis diretamente no software. Uma das que vi a possibilidade é o Scrum e por isso resolvi postar sobre essa metodologia ágil.

O Scrum é uma metodologia ágil para Gerenciamento de Projetos.

Inicialmente, o Scrum foi concebido como um estilo de gerenciamento de projetos em empresas de fabricação de automóveis e produtos de consumo, por Takeuchi e Nonaka no artigo “The New Product Development Game” (Harvard Business Review, Janeiro-Fevereiro 1986). Eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação Scrum do Rugby (utilizada para reinício do jogo em certos casos). Jeff Sutherland, John Scumniotales, e Jeff McKenna conceberam, documentaram e implementaram o Scrum, como descrito abaixo, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. Em 1995, Ken Schwaber formalizou a definição de Scrum e ajudou a implantá-lo em desenvolvimento de software em todo o mundo.

Scrum junta conceitos de Lean, desenvolvimento iterativo e do estudo de Hirotaka Takeuchi e Ikujiro Nonaka.

A função primária do Scrum é ser utilizado para o gerenciamento de projetos de desenvolvimento de software. Ele tem sido usado com sucesso para isso, assim como Extreme Programming e outras metodologias de desenvolvimento. Porém, teoricamente pode ser aplicado em qualquer contexto no qual um grupo de pessoas necessitem trabalhar juntas para atingir um objetivo comum, como iniciar uma escola pequena, projetos de pesquisa científica, ou até mesmo o planejamento de um casamento.

Mesmo que idealizado para ser utilizado em gestão de projetos de desenvolvimento de software ele também pode ser usado para a gerência de equipes de manutenção, ou como uma abordagem para gestão de programas: Scrum de Scrums.

Características de Scrum

Cada sprint é uma iteração que segue o (ciclo PDCA) e entrega incremento de software pronto.
Um backlog é conjunto de requisitos, priorizado pelo Product Owner (Responsável pelo ROI e por conhecer as necessidades do cliente);
Há entrega de conjunto fixo de itens do backlog em série de interações curtas ou sprints;
Breve reunião diária, ou daily scrum, em que cada participante fala sobre o progresso conseguido, o trabalho a ser realizado e/ou o que o impede de seguir avançando (também chamado de Standup Meeting ou Daily Meeting, já que os membros da equipa geralmente ficam em pé para não prolongar a reunião).
Breve sessão de planejamento, na qual os itens do backlog para uma sprint (iteração) são definidos;
Retrospectiva, na qual todos os membros da equipe refletem sobre a sprint passada.

O Scrum é facilitado por um Scrum Master, que tem como função primária remover qualquer impedimento à habilidade de uma equipe de entregar o objetivo do sprint. O Scrum Master não é o líder da equipe (já que as equipes são auto-organizadas), mas atua como um mediador entre a equipe e qualquer influência desestabilizadora. Outra função extremamente importante de um Scrum Master é o de assegurar que a equipe esteja utilizando corretamente as práticas de Scrum, motivando-os e mantendo o foco na meta da Sprint.

Scrum permite a criação de equipes auto-organizadas, encorajando a comunicação verbal entre todos os membros da equipe e entre todas as disciplinas que estão envolvidas no projeto.

Um princípio chave do Scrum é o reconhecimento de que desafios fundamentalmente empíricos não podem ser resolvidos com sucesso utilizando uma abordagem tradicional de “controle”. Assim, o Scrum adota uma abordagem empírica, aceitando que o problema não pode ser totalmente entendido ou definido, focando na maximização da habilidade da equipe de responder de forma ágil aos desafios emergentes.

Um dos grandes defeitos do Scrum, porém, é a abordagem de “receita de bolo” do gerenciamento de projetos exemplificado no Project Management Body of Knowledge ou PRINCE2, que tem como objetivos atingir qualidade através da aplicação de uma série de processos prescritos.

Backlog de produto e backlog de sprint

Um backlog é uma lista de itens priorizados a serem desenvolvidos para um software. O backlog de produto é mantido pelo Proprietário do Produto e é uma lista de requisitos que tipicamente vêm do cliente. O backlog de sprint é uma interpretação do backlog do produto e contém tarefas concretas que serão realizadas durante o próximo sprint para implementar alguns dos itens principais no backlog do produto. O backlog de produto e de sprint são, então, duas coisas totalmente diferentes, o primeiro contendo requisitos de alto-nível e o segundo contendo informações sobre como a equipe irá implementar os requisitos do produto.

Planejamento de sprint

Antes de todo sprint, o Proprietário do Produto, o Scrum Master e a Equipe decidem no que a equipe irá trabalhar durante o próximo sprint. O Proprietário do Produto mantém uma lista priorizada de itens de backlog, o backlog do produto, o que pode ser repriorizado durante o planejamento do sprint. A Equipe seleciona itens do topo do backlog do produto. Eles selecionam somente o quanto de trabalho eles podem executar para terminar. A Equipe então planeja a arquitetura e o design de como o backlog do produto pode ser implementado. Os itens do backlog do produto são então destrinchados em tarefas que se tornam o backlog do sprint.

Scrum simplificado

Muitas organizações têm sido resistentes às metodologias introduzidas em baixos níveis da organização. Porém, a adaptabilidade do Scrum permite que ele seja introduzido de forma invisível (“stealth”), usando os três passos:

Agende uma demonstração do software com seu cliente em um mês a partir de agora;
Como equipe, tome um mês para deixar o software pronto para uma demo, com funcionalidades prontas, não simplesmente telas;
Na demonstração, obtenha feedback e use-o para guiar o seu próximo mês de trabalho de desenvolvimento.

Algumas características de Scrum

Clientes se tornam parte da equipe de desenvolvimento (os clientes devem estar genuinamente interessados na saída);
Entregas frequentes e intermediárias de funcionalidades 100% desenvolvidas;
Planos frequentes de mitigação de riscos desenvolvidos pela equipe;
Discussões diárias de status com a equipe;
A discussão diária na qual cada membro da equipe responde às seguintes perguntas:
- O que fiz desde ontem?
- O que estou planejando fazer até amanhã?
- Existe algo me impedindo de atingir minha meta?
Transparência no planejamento e desenvolvimento;
Reuniões frequentes com os stakeholders (todos os envolvidos no processo) para monitorar o progresso;
Problemas não são ignorados e ninguém é penalizado por reconhecer ou descrever qualquer problema não visto;
Locais e horas de trabalho devem ser energizadas, no sentido de que “trabalhar horas extras” não necessariamente significa “produzir mais”.

Agendando discussões diárias

Um momento bom para as discussões diárias é depois do almoço. Durante a manhã pode ser complicado. Estas discussões de status não demoram e uma forma eficiente de fazer estas reuniões seria ficar em pé e em frente a um quadro negro. Como as pessoas tendem a ficar cansadas depois do almoço, ter uma viva reunião em pé nessa hora permite que a equipe mantenha a sua energia alta. Como todos estiveram trabalhando durante a manhã, suas mentes estão focadas no trabalho e não em questões pessoais.

Scrum Solo

Scrum é baseado em pequenas equipes. Ele permite a comunicação entre os membros da equipe. Entretanto, há uma grande quantidade de softwares desenvolvidos por programadores solos. Um software sendo desenvolvido por um só programador pode ainda se beneficiar de alguns princípios do Scrum, como: um backlog de produto, um backlog de sprint, um sprint e uma retrospectiva de sprint. Scrum Solo é uma versão adaptada para uso de programadores solo.

Fonte: Wikipedia

Posted from Vila Velha, Espírito Santo, Brazil.

Rating: 0.0/10 (0 votes cast)

Compartilhe: