SCRUM - Implantação XII

Resposta a mudanças, mais que seguir um plano

Toda mudança é bem-vinda. A equipe Scrum reconhece que a única certeza que temos em um projeto são as mudanças. Mesmo porque, não somos especialistas em todos os domínios de negócio existente, e o conceito de unicidade dos projetos nos torna flexíveis, pois ao logo do desenvolvimento podem existir divergências no entendimento, por não conhecermos a fundo o seu domínio. É durante o ciclo de vida do projeto que o time de desenvolvimento aprende sobre o domínio do negócio, em contato constante com o especialista do negócio, representante legal da empresa. Essa flexibilidade, característica fundamental das equipes ágeis, possibilita que o time responda rápido as mudanças.

Grande Abraço,
Gilberto Ribeiro.

Métrica de Software - XII

Após todo esse processo o que fazer com as entidades que sobraram?

Se não deixamos passar nada teoricamente as entidades que sobram são arquivos lógicos.

Observando as informações

As perspectivas de negócio do usuário quanto aos dados é refletida em como as transações os consultam e/ou atualizam. Verifique como os processos elementares da aplicação matem essas entidades. A inclusão e exclusão conjunta de determinado grupo de entidades é um forte indicador que esse grupo deve ser considerado único arquivo lógico. A alteração de dados normalmente está direcionada apenas para uma única entidade; consequentemente, ela não é uma orientação efetiva para agrupar entidades. Identifique os processos elementares de extração que consultam essas entidades e verifique se elas também são consultadas conjuntamente.

Uma ordem de serviço (OS) de ter as informações que identificam qual cliente a solicitou, a data de entrada, o prazo estimado, seu responsável e os vários itens envolvidos em sua execução. Durante a modelagem de dados foram especificadas as entidades Ordem de Serviço e Item da OS para atender a esse requisito de armazenamento. Os processos OS-Incluir e OS-Excluir também operam sobre estas entidades. Não é possível incluir uma OS sem que os itens sejam incluídos, assim como não é possível manter um itens sem a OS.

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - XII

Escritório de projetos

Um escritório de projetos (Project Management Office, PMO) é um corpo ou entidade organizacional à qual são atribuídas várias responsabilidades relacionadas ao gerenciamento centralizado e coordenado dos projetos sob seu domínio. As responsabilidades de um PMO podem variar desde fornecer funções de suporte ao gerenciamento de projetos até ser responsável pelo gerenciamento direto de um projeto.

Os projetos apoiados ou administrados pelo PMO podem não estar relacionados de outra forma que não seja por serem gerenciados conjuntamente. A forma, função e estrutura específicas de um PMO depende das necessidades da organização à qual ele dá suporte.

Um PMO pode receber uma autoridade delegada para atuar como parte interessada integral e um importante deliberante durante o início de cada projeto, fazer recomendações ou encerrar projetos, ou ainda tomar outras medidas conforme a necessidade para manter os objetivos de negócios consistentes. Além disso, o PMO pode estar envolvido na seleção, no gerenciamento e na mobilização de recursos de projetos compartilhados ou dedicados.

A principal função de um PMO é dar suporte aos gerentes de projetos de diversas maneiras, que incluem mas não se limitam a:

• Gerenciamento de recursos compartilhados entre todos os projetos administrados pelo PMO;
• Identificação e desenvolvimento de metodologia, melhores práticas e padrões de gerenciamento de projetos;
• Orientação, aconselhamento, treinamento e supervisão;
• Monitoramento da conformidade com as políticas, procedimentos e modelos padrões de gerenciamento de projetos por meio de auditorias do projeto;
• Desenvolvimento e gerenciamento de políticas, procedimentos, formulários e outras documentações compartilhadas do projeto (ativos de processos  organizacionais) e
• Coordenação das comunicações entre projetos.
• Os gerentes de projetos e os PMOs buscam objetivos diferentes e, por isso, são orientados por requisitos diferentes. No entanto, todos esses esforços estão alinhados com as necessidades estratégicas da organização. As diferenças entre o papel dos gerentes de projeto e de um PMO podem incluir:
• O gerente de projetos concentra-se nos objetivos especificados do projeto, enquanto o PMO gerencia as principais mudanças do escopo do programa que podem ser vistas como possíveis oportunidades para melhor alcançar os objetivos de negócios;
• O gerente de projetos controla os recursos atribuídos ao projeto para atender da melhor forma possível aos objetivos do projeto, enquanto que o PMO otimiza o uso dos recursos organizacionais compartilhados entre todos os projetos;
• O gerente de projetos gerencia as restrições (escopo, cronograma, custo e qualidade, etc.) dos projetos individuais, enquanto o PMO gerencia as metodologias, padrões, o risco/oportunidade global e as interdependências entre os projetos no nível da empresa.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XII

Modelo de Estratégia de Implantação

Considerando os seguintes pontos:

1. Como iremos estruturar ao deliverables do WBS – Work Breakdown Structure ou EAP - Estrutura Analítica do Projeto?
2. A estratégia vai ser o desenvolvimento interno de toda a fábrica?
3. Qual o ciclo de vida a ser adotado para o projeto?
4. Qual a estratégia para entrega de produto a longo tempo (por partes ou tudo de uma vez?)
5. Quais os requerimentos do plano de qualidade do projeto?
6. Quais os requerimentos para estrutura organizacional do projeto?
7. Quais os requerimentos para o planejamento de recursos?
8. Quais os requerimentos para o plano de risco?
9. Quais os requerimentos para o comunicação do projeto?
10. Quais os requerimentos de envolvimento de pessoas chaves durante o desenvolvimento do planejamento?

As respostas a essas questões vão orientar a equipe responsável pela execução do produto.

Os passos para o desenvolvimento da estratégia do projeto são:

1. Analisar a especificação da fábrica de software, visando alinhar a estratégia de desenvolvimento do projeto.
2. Verificar a experiência em projetos com as mesmas características no mercado para obter informações sobre as lições aprendidas.
3. Definir a estrutura básica do WBS, considerando as frentes de trabalho esperada para o projeto, que mereçam destaque.
4. Ao definir as frentes de trabalho ou conjunto de deliverables, identificar:
• O conjunto principal do produto (produto final).
• Os conjuntos de apoio e secundário que são importantes para a geração do produto final.
5. Decidir sobre a estratégia de desenvolvimento do produto resultante do projeto, considerando:
• As alternativa de desenvolvimento interno, integral ou parcial
• Contratação de terceiros integral ou parcial
• Aquisição de pacotes
• Envolvimento de fornecedores
• Contratação de pessoas que já vivenciaram projetos dessa natureza etc.
6. Decidir sobre o ciclo de vida a ser adotado para o desenvolvimento do projeto (podemos utilizar um ciclo de vida para cada tipo de deliverables do projeto, considerando as frentes de trabalho definidas pelas estrutura do WBS – Work Breakdown Structure).
7. Decidir sobre como os produtos vão ser entregues ao longo do tempo, devido às restrições de prazo e custo (a entrega do produto também está associada ao ciclo de vida selecionado para o projeto)
8. Definir os requisitos do plano da qualidade do projeto, como decidir sobre uso de revisões, ambientes de testes estruturados, papel do Q.A.- Quality Assurance, uso de padrões etc. (esses requisitos servem de guia para o Plano de Qualidade do Projeto);
9. Definir os requisitos de Plano Organizacional do Projeto em termos de: (esses requisitos servem de guia para a elaboração do Plano Organizacional do Projeto).
• Uso de “Comitê de Projeto”.
• Sobre “quem” é imprescindível para participar nesse comitê.
• Quais formadores de opinião devem ser trabalhados.
• Qual a qualificação dos recursos humanos requeridas etc.
10. Definir os requisitos para o Planejamento da Aquisição do Projeto em termos de: (também serve de guia para a elaboração do Plano de Aquisições do Projeto)
• Tipo e qualificação de recursos
• Parceiros e fornecedores
• Tipos de equipamentos etc.
11. Definir os requisitos para o Plano de Riscos em termos de:
• Pontos de atenção em função do tipo de projeto.
• Indicar os riscos prováveis do projeto, conforme conhecimento de práticas do mercado.
12. Definir os requisitos para o Plano de Comunicação do Projeto, considerando:
• Os meios usuais de comunicação e relatórios já empregado pela empresa ou em função das características da audiência.
• Identificar os meios adequados em vista da cultura da empresa.
13. Definir qual a estratégia básica de envolvimento das pessoas chaves no projeto:
• Quem da equipe do projeto deve “trabalhar”.
• Quem da equipe dos stakeholders deve ser envolvido no projeto.
• Como os stakeholders deverão ser envolvidos durante o planejamento do projeto e nas aprovações e homologações intermediárias, caso seja necessário.
14. Definir os pontos de revisão dos produtos do planejamento do projeto antes das apresentações para os stakeholders e gestor do projeto.
15. Definir a estratégia de homologação evolutiva dos produtos do planejamento junto aos stakeholders e gestor do projeto.
16. Documentar a estratégia de desenvolvimento.

Grande Abraço,

Gilberto Ribeiro.

Engenharia de Software - XII

Modelo de Qualidade para Qualidade em Uso segundo a Norma ISO 9126

Esta seção define o modelo de qualidade para qualidade em uso. Os atributos de qualidade em uso são categorizados em quatro características: eficácia, produtividade, segurança e satisfação.

Qualidade em uso é a visão da qualidade sob a perspectiva do usuário. A obtenção de qualidade em uso é dependente da obtenção da necessária qualidade externa, a qual, por sua vez, é dependente da obtenção da necessária qualidade interna. Normalmente, são necessárias medidas em todos os três níveis, pois atender aos critérios para medidas internas em geral não é suficiente para garantir o atendimento aos critérios para medidas externas, e atender aos critérios para medidas externas de sub-características em geral não é suficiente para garantir o atendimento aos critérios para qualidade em uso.

Qualidade em uso

“Capacidade do produto de software de permitir que usuários especificados atinjam metas especificadas com eficácia, produtividade, segurança e satisfação em contextos de uso especificados”. (NBR ISO/IEC 9126)

Grande Abraço,

Gilberto Ribeiro.