Ok … vamos voltar à nossa discussão sobre a forma de olhar para o PMI áreas de conhecimento mais ágil um ponto de vista. Última vez que abordou Custo de Gestão, este post vamos olhar Âmbito Gestão
De acordo com a terceira edição do Project Management Body of Knowledge, Scope Management inclui os processos necessários para assegurar que o projecto inclui todos os trabalhos necessários, e apenas o trabalho necessário, para completar o projeto com sucesso. PMI estados âmbito desse projecto de gestão em causa é essencialmente a tarefa de definir e controlar o que é e não está incluído no projeto.
Acho que é um pouco divertido fazer estas declarações parecem ser universalmente interpretada como “definir tudo o que você pretende fazer na frente e certifique-se de concretizar o que foi inicialmente definido”. Enquanto que pode ter sido a intenção do PMBOK Guide, alguns projetos não se prestam a esse tipo de planejamento na frente. Alguns projectos deverão permitir a descoberta. Alguns projectos terão de se adaptar à evolução dos mercados, ou, pelo menos, adaptar baseada na compreensão das equipas emergentes produto.
Para alguns de nós trabalham em domínios mais dinâmico problema, garantindo que “o projeto inclui todo o trabalho necessário”, é um processo de descoberta. Controlar o que está incluído eo que não está incluído, é uma preocupação permanente e não algo feito uma vez para todo o projeto. Precisamos de um quadro de gestão de projectos que abraça essa incerteza e não desejando-la ou fingir que não existem.
Estou convencido de que os gestores de projectos tornar-se padrão para este ponto de vista estático, porque nunca fomos ensinados outra forma de gestão dos projectos. Nós só não tem ferramentas para entregar projectos qualquer outra forma. Então … isto dito, vamos ter um momento de olhar para o PMI Âmbito Gestão processos mais ágeis a partir de um ponto de vista. Aposto que encontrar outra maneira de abordar Âmbito Gestão que não envolve definir tudo na frente e, depois, travando-a para baixo para a duração do projecto.
Âmbito Planejamento
PMI Definição: Criar um plano de gestão que o projeto alcance documentos como o âmbito de aplicação será definido, verificado, controlado, e como o trabalho Discriminação Estrutura será criada e definida
Agile projecto práticas de gestão são realmente a encarnação de uma abordagem de planeamento alcance. Como um gestor de projecto, nomeadamente um gestor de projecto tradicional fazendo a transição para Agile, não tenho qualquer problema documentar isso para a minha organização. Um Plano de Gestão Ágil Âmbito vai abordar assuntos como a criação do atraso, as características de uma boa carteira item, como é que vamos estabelecer velocidade ou débito, como é que vamos para medir burndown contra o atraso, e como é que vamos para lidar com as mudanças para o atraso.
Âmbito Definição
PMI Definição: Desenvolver um projeto detalhado âmbito declaração como a base para futuras discussões projecto
Âmbito sobre Agile um projeto é definido no produto atraso. O atraso é uma listagem das características que o seu produto proprietário gostaria de ter incluído no seu projecto. Uma das mais importantes considerações a ter em conta é que cada item do atraso devem ser independentes uns dos outros. Este é o molho secreto que torna possível reprioritize e fazer alterações na mosca. Acorde Bill tem uma grande explicação sobre o que faz um bom atraso item na sua página: http://xp123.com/xplor/xp0308/index.shtml.
Ao invés de olhar para o atraso como um produto estático indicador do que será construído, olha para ele como a base para uma maior adaptação. Prevê-se a mudar à medida que aprender mais sobre o surgimento do produto.
Criar WBS
PMI Definição: subdividir os grandes projecto e trabalhos em pequenos, mais administrável componentes
Esta é uma das coisas mais difíceis para os gestores de projectos tradicionais, para obter a sua cabeça ao redor. Não há WBS em um projeto Ágil, pelo menos não em um sentido tradicional do termo. Definição do âmbito seção, nós aprendemos que o nosso atraso representa o escopo do projeto e que cada um dos itens atraso devem ser independentes uns dos outros. A independência é fundamental porque nos permite fazer exatamente no tempo de programação.
Agile projectos são repartidos em pequenos projectos chamados lançamentos. Projeto lançamentos são discriminados em menor tempo de caixas chamado iterações. O conteúdo é puxado em um lançamento pouco antes de seu início, e apenas como a versão anterior é sinuoso baixo. Da mesma forma, o conteúdo só é puxado para a próxima iteração como o anterior iteração está chegando ao fim. A idéia aqui é que vamos rever o que a equipa foi capaz de completar e tomar decisões sobre o próximo incremento baseadas naquilo que aprendemos com a entrega do incremento anterior.
Como um Agile Project Manager, estou confortável geral que define um plano de alto nível para entender onde eu esperar ser em certos pontos do projeto. Também estou confortável mantendo um gráfico de dependências internas e externas para ajudar a gerenciar compromissos. A chave é a utilização destas como orientação para a tomada de decisão e indicadores de progresso. Os problemas surgem quando essas ferramentas restringir a nossa capacidade de aprender e adaptar-se às realidades dos nossos projectos.
Âmbito Verificação
PMI Definição: Formalizing aceitação do projecto concluído
Cada iteração iremos decidir os próximos melhores incremento para a construção e, em seguida, analisar os resultados, uma vez que estamos a concluir. Os interessados aceitar ou rejeitar o resultado da iteração e trabalhar com a equipe para decidir o melhor conjunto de funcionalidades para construir.
Porque queremos manter a capacidade de ajustar o produto, como se aprende mais sobre a solução emergentes, nos concentramos em fazer reuniões e compromissos em pequenos incrementos. Âmbito verificação é feita com base no resultado destes pequenos incrementos de produto e como elas alinhar com o produto visão e os objetivos da libertação.
Âmbito Controle
PMI Definição: Controlar alterações ao projecto alcance
Agile equipas ter uma abordagem orientada para o valor para entrega em vez de uma atividade baseada, ou mesmo prestações baseado, abordagem para entrega de projectos. O produto proprietário pode alterar o âmbito de aplicação do produto em caso de dúvida, mas está sempre focada em fornecer o maior valor possível tendo em conta o tempo disponível e recursos.
Agile equipas dão o produto proprietário uma tremenda quantidade de poder discricionário sobre o modo como o sistema é construído e até mesmo tardia acomodar mudanças na vida do projecto. Entende-se por Agile equipes que mudar âmbito envolve tradeoffs. O produto proprietário está substituindo características que agregam mais valor para aqueles que oferecem menos. Para acrescentar uma coisa, algo muitas vezes tem de ser retirados.