CMMI e Ágil

CMMI e Ágil

Os modelos do SW-CMMI consideram tanto questões relacionadas a implementação e processos eficazes e eficientes quanto a melhoria sistemática de processos.

Diversos estudos afirmam que essas duas categorias de métodos (CMMI ou CMM e métodos ágeis) podem ser empregadas conjuntamente, criando uma sinergia que possibilita que as organizações que os utilizam se beneficiem das vantagens trazidas por ambas.

O XP possui algumas características em comum com todos os níveis de maturidade do CMM, inclusive o nível 5.

Grande Abraço,
Gilberto Ribeiro.

O Propósito do Guia SCRUM - X

36. Quais são os três pilares do SCRUM?

• TRANSPARÊNCIA

• Aspectos significativos do processo e do projeto devem estar visíveis para os responsáveis pelos resultados.
• Passar as informações de forma clara e precisa, possibilitando que todos tenham o mesmo entendimento.
• Valor do SCRUM que deve ser praticado por todos os papéis e envolvidos no projeto.
• Ter transparência é falar a mesma coisa, independente de quem fez a pergunta.
• No SCRUM as coisas devem ser claras e visíveis para todos.
• Visíveis a todos os interessados das atividades e seu andamento.
• Fazer estimativas baseadas naquilo que se realmente acredita

• INSPEÇÃO

• As práticas e atividades SCRUM, devem ser inspecionadas com frequência para que as variações possam ser detectadas o mais cedo possível.
• Evita que o cliente receba um produto com qualidade inadequada.

• ADAPTAÇÃO

• Sempre que um evento não desejado ocorrer, adaptamos o processo para evitar a sua recorrência.
• Inspeção e adaptação costumam ocorrer juntas e a equipe é quem deve realizar.

37. Como podemos entender a TRANSPARÊNCIA?

• Como a visibilidade de todos os aspectos significativos do processo dada aos responsáveis pelos resultados do projeto.

A transparência requer aspectos definidos por um padrão comum para que os observadores compartilhem um mesmo entendimento do que está sendo visto.

38. Práticas de transparências:

• Uma linguagem comum referindo-se ao processo deve ser compartilhado por todos os participantes.
• Uma definição comum de PRONTO deve ser compartilhada por aqueles que realizam o trabalho e por aqueles que aceitam o resultado do trabalho.

39. Qual a função da INSPEÇÃO no SCRUM?

• Inspecionar os artefatos SCRUM e o progresso em direção ao objetivo, identificando as possíveis variações.

40. Qual a frequência das inspeções?

• Não devem ser muito frequentes na equipe de desenvolvimento, para não atrapalhar as tarefas.

41. Quando as inspeções são mais eficazes?

• Quando dirigidas aos especialistas no trabalho em desenvolvimento.

42. Quando uma adaptação ocorre no SCRUM?

• Quando são identificados desvios no processo fora dos limites aceitáveis, inviabilizando a aceitação do produto.

No SCRUM existem 4 eventos formais que podem ser aproveitados para a realização da inspeção e adaptação:

• Reunião de planejamento da Sprint.
• Reunião diária
• Revisão da Sprint
• Retrospectiva da Sprint

43. Quais os eventos do SCRUM ideais para inspecionar e adaptar o processo?

• Reunião de Planejamento da Sprint.
• Reunião diária.
• Reunião de Revisão da Sprint.
• Retrospectiva da Sprint.

Grande Abraço,
Gilberto Ribeiro.

Requisitos - XIV

Codificação

A etapa de codificação envolve o desenvolvimento em si do projeto.

Ambiente de codificação

• Os desenvolvedores devem possuir um ambiente apartado no qual tenham total controle de forma a poderem rapidamente resolver problemas nas máquinas.
• A equipe de suporte deve dar total apoio aos desenvolvedores, tal como em termos de instalação das máquinas, backup e solução rápida de problemas que sejam exclusivamente de infraestrutura. Deve também procurar, junto com o analista, as melhores técnicas de otimização do ambiente de codificação.
• Deve estar em uso um sistema de controle de versões.

Ocorrências comuns no ambiente de codificação

Alterações no modelo de dados

• Devem ser aprovadas pela equipe de banco de dados e deve ser gerado um script evolutivo que será armazenado juntamente com script 0 do banco de dados. 

Alterações no protótipo

• Devem ser aprovadas pelo usuário
• Alterações na modelagem do sistema
• Alterações no desenho do processo
• Essas duas últimas podem ter impacto médio a grande no desenvolvimento do sistema. É importante verificar se é realmente absolutamente necessário que essas modificações sejam feitas ou se seria possível que essas modificações fossem implementadas apenas em uma versão 2 do sistema.
• Caso seja absolutamente necessária a realização destas modificações o cronograma do sistema deve ser corrigido com base no impacto destas mudanças.
• Normalmente mudanças deste porte causam as outras 2, alteração de protótipo e de modelo de dados

O trabalho do analista 

O analista aproveita o período de desenvolvimento, no qual seu trabalho fica mais direcionado à gerencia de projeto, para realizar as seguintes tarefas :

• Criar um plano de testes para a aplicação
• Realizar o “teste de bancada”, teste inicial ainda em ambiente de desenvolvimento, conforme os desenvolvedores terminam cada trecho da aplicação
• Planejar o teste de stress em conjunto com a equipe de suporte
• Planejar o processo de implantação da aplicação em conjunto com a equipe de suporte e banco de dados

Cronograma e desempenho 

Uma técnica muito útil para a análise de tempo gasto em desenvolvimento é a análise de pontos de função.

Esta análise intenciona quantificar o software que está sendo desenvolvido em pontos de função e identificar a produtividade dos desenvolvedores também em pontos de função/dia.

Com isso consegue-se :

• Identificar os desenvolvedores muito e pouco produtivos
• Montar cronogramas mais precisos com base na produtividade real dos desenvolvedores
• Identificar a necessidade de mais desenvolvedores para cumprir um determinado prazo
• Identificar mais precisamente os custos do projeto

A análise de ponto de função é muito detalhista e normalmente demanda tempo na etapa de análise, por isso é muito comum as empresas criarem pequenas adaptações desta análise conforme a arquitetura utilizada.

Grande Abraço,

Gilberto Ribeiro.

O Propósito do Guia SCRUM - IX

Product Owner - PO

26. Qual a principal função do Product Owner?

• É o responsável por maximizar o valor do produto e do trabalho da equipe de desenvolvimento.

O Product Owner é a única pessoa responsável por gerenciar o Backlog do Produto.

27. Quais atividades podemos listar como gestão do backlog do produto?

• Expressar claramente os itens do Backlog do Produto.
• Ordenar os itens do Backlog do Produto do projeto para alcançar as metas e missão do projeto.
• Garantir o valor do trabalho realizado pelo time de desenvolvimento.
• Garantir que o Backlog do Produto seja:
• Visível
• Transparente
• Claro para todos
• Mostrar o que o time de SCRUM irá trabalhar a seguir
• Garantir que a equipe de desenvolvimento entenda os itens do Backlog do Produto satisfatoriamente para o seu desenvolvimento.

O Product Owner pode delegar as atividades acima para a equipe do projeto, mas ele continua sendo o responsável. Ele é uma pessoa e não um comitê, todas as solicitações de alterações devem ser dirigidas a ele.

28. Como garantir o sucesso do Product Owner?

• Respeitando as suas decisões.

Todas as decisões do Product Owner devem ser visíveis no conteúdo e na priorização do Backlog do Produto.

O Scrum Master
 

29. Qual o papel do Scrum Master?

• Garantir que o Scrum seja entendido e aplicado, de forma que o Time Scrum conheça à teoria, práticas e regras do Scrum.
• Ajudar aqueles que estão fora do Time Scrum a entender quais as suas interações com o Time Scrum são úteis e quais não são.
• Ajudar a todos a mudarem as interações para maximizar o valor criado pelo Time Scrum.

30. Como o Scrum Master trabalha para o Product Owner?

• Encontrando técnicas para o gerenciamento efetivo do Backlog do Produto;
• Comunicando a visão, objetivo e itens do Backlog do Produto para a Equipe de Desenvolvimento;
• Ensinando a Time Scrum a criar itens de Backlog do Produto de forma clara e concisa;
• Compreendendo a longo-prazo o planejamento do Produto no ambiente empírico;
• Compreendendo e praticar a agilidade; e,
• Facilitando os eventos Scrum conforme exigidos ou necessários.

31. Como o Scrum Master trabalha para a Equipe de Desenvolvimento?

• Treinando a Equipe de Desenvolvimento em auto gerenciamento e interdisciplinaridade;
• Ensinando e liderando a Equipe de Desenvolvimento na criação de produtos de alto valor;
• Removendo impedimentos para o progresso da Equipe de Desenvolvimento;
• Facilitando os eventos Scrum conforme exigidos ou necessários; e,
• Treinando a Equipe de Desenvolvimento em ambientes organizacionais nos quais o Scrum não é totalmente adotado e compreendido.

32. Como o Scrum Master trabalha para a organização?

• Liderando e treinando a organização na adoção do Scrum;
• Planejando implementações Scrum dentro da organização;
• Ajudando funcionários e partes interessadas a compreender e tornar aplicável o Scrum e o desenvolvimento de produto empírico;
• Causando mudanças que aumentam a produtividade do Time Scrum; e,
• Trabalhando com outro Scrum Master para aumentar a eficácia da aplicação do Scrum nas organizações.

Equipe de Desenvolvimento

A Equipe de Desenvolvimento consiste de profissionais que realizam o trabalho de entregar uma versão usável que potencialmente incrementa o produto “Pronto” ao final de cada Sprint. Somente integrantes da Equipe de Desenvolvimento criam incrementos.

As Equipes de Desenvolvimento são estruturadas e autorizadas pela organização para organizar e gerenciar seu próprio trabalho. A sinergia resultante aperfeiçoa a eficiência e a eficácia da Equipe de Desenvolvimento como um todo.

33. Quais as características da Equipe de Desenvolvimento?

• São auto-organizadas. Ninguém diz a Equipe de Desenvolvimento como transformar o Backlog do Produto em incrementos de funcionalidades potencialmente utilizáveis;
• Equipes de Desenvolvimento são multifuncionais, possuindo todas as habilidades necessárias, enquanto equipe, para criar o incremento do Produto.
• O Scrum não reconhece títulos para os integrantes da Equipe de Desenvolvimento que não seja o de Desenvolvedor, independentemente do trabalho que está sendo realizado pela pessoa; Não há exceções para esta regra.
• Individualmente os integrantes da Equipe de Desenvolvimento podem ter habilidades especializadas e área de especialização, mas a responsabilidade pertence à Equipe de Desenvolvimento como um todo; e,
• Equipes de Desenvolvimento não contém subequipes dedicadas a domínios específicos de conhecimento, tais como teste ou análise de negócios.

34. Qual o tamanho ideal para a equipe de Desenvolvimento?

• Cinco a nove desenvolvedores, ou seja, pequena o suficiente para se manter ágil e grande o suficiente para completar uma parcela significativa do trabalho.

35. Quais os problemas das equipes pequenas?

• Menos de três integrantes na Equipe de Desenvolvimento diminuem a interação e resultam em um menor ganho de produtividade. Equipes de desenvolvimento menores podem encontrar restrições de habilidades durante a Sprint, gerando uma Equipe de Desenvolvimento incapaz de entregar um incremento potencialmente utilizável.

35. Quais os problemas das equipes grandes?

• Mais de nove integrantes é exigida muita coordenação. Equipes de Desenvolvimento grandes geram muita complexidade para um processo empírico gerenciar.

Ao menos que eles também executem o trabalho do Backlog da Sprint, o Product Owner e o Scrum Master não podem ser contados como integrantes da equipe de desenvolvimento.

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XIII

Análise

A etapa de análise é a etapa na qual se faz o levantamento da necessidade existente e define-se de que forma o software a ser criado deverá solucionar esta necessidade.

Em alguns ambientes os desenvolvedores tem o mal costume de pular a etapa de análise passando diretamente a etapa de desenvolvimento. Isso causa frequentemente falhas na definição do software, ou seja, descobre-se após o desenvolvimento que o que foi feito não atende a necessidade existente.

Divisões da etapa de análise

• Levantamento de informações
• Desenho de processo (Use Cases)
• Modelagem de Dados (MER)
• Modelagem do sistema
• Prototipação
• Definições finais

Levantamento de Informações (Analista de Requisitos e de Sistema)

Nesta etapa o analista realiza o levantamento de informações com o usuário. O analista faz uso de muitas entrevistas com o usuário para descobrir as necessidades existentes.

• O analista deve estar atento as informações fornecidas pelo usuário, cada detalhe mencionado por usuário as vezes pode resultar em mudanças no planejamento que o analista já estava realizando.
• O analista não deve se confundir quando o usuário tentar indicar como algo deve ser feito fisicamente (estrutura de tabela, tela, programas, etc.). O usuário não tem conhecimento técnico para fazer essa indicação, o analista deve extrair do usuário apenas as especificações ligadas ao negócio da empresa.
• Nem sempre o usuário tem todas as informações que o analista precisa. Muitas vezes o usuário tem uma informação sobre o seu trabalho no momento, mas a diretoria tem um planejamento futuro em relação ao trabalho que afeta a aplicação e não é de conhecimento do usuário. Assim sendo o analista deve consultar outras pessoas além dos usuários da aplicação.

Desenho de Processo

• O desenho de processo é realizado com os dados colhidos no levantamento de informações. É uma demonstração gráfica da forma de funcionamento do negócio descrito pelo usuário.
• O desenho de processo é utilizado para apresentar o resultado do levantamento ao usuário. Na verdade as duas etapas são recorrentes, caso o usuário identifique erros no desenho de processo volta-se ao levantamento para acerta-los e assim consecutivamente até que o usuário aprove o desenho de processo.

Modelagem de Dados

Tendo o desenho de processo sido realizado parte-se para o modelo de dados. A criação do modelo de dados irá novamente se utilizar das informações obtidas durante o levantamento, mas poderá também ter necessidade de novas informações e obrigar o analista a retornar para a etapa de levantamento.

• O modelo de dados não é tão compreensível para um usuário leigo como o desenho de processo, portanto apresenta-lo ou não ao usuário pode ser uma decisão do analista.
• O modelo de dados deve ser dividido em lógico e físico, um estando mais próximo das características do negócio enquanto o outro demonstrando características físicas do banco de dados.
• O analista de sistemas nem sempre é um DBA, portanto o modelo de dados deve ser aprovado pela equipe de administradores de dados.
• Tendo o modelo de dados sido aprovado gera-se um script 0 do banco de dados, o script inicial deste banco
• Toda futura alteração do modelo de dados deve  ter a aprovação do DBA, que aproveita seu conhecimento das alterações para se preparar para a fase de implantação. As alteração são realizadas na forma de scripts evolutivos do banco de dados de forma a complementarem o script 0. Assim sendo ganha-se uma sequencia histórica de mudanças realizadas no banco de dados.

Modelagem do Sistema

Feita a modelagem de dados, modela-se o sistema que irá manipular esses dados. Pode-se utilizar DFDs, típicos da análise estruturada, ou diagramas de classe e Sequências, típicos da análise orientada a objetos.

• Obtêm-se como resultado desta etapa descrições gráficas dos módulos que serão gerados no sistema, quer sejam formulários/funções em aplicações estruturadas quer sejam classes/componentes em aplicações orientadas a objeto.
• Todas as etapas de análise são interligadas. A modelagem do sistema pode afetar todas as etapas anteriores, eventualmente exigindo que o analista retorne ao levantamento.
• É papel do analista, durante este processo, realizar suposições sobre diversas situações de negócio que porventura o usuário não tenha imaginado, garantindo assim que o sistema funcione de forma flexível mesmo frente a situações inesperadas. 

Prototipação

Feita a modelagem do sistema parte-se então para a construção do protótipo.

• O protótipo é um modelo das telas do sistema que tem por intenção obter do usuário a aprovação da navegabilidade do sistema e da forma como suas funcionalidades serão visualmente implementadas. 

Definições finais

Tendo obtido a aprovação do usuário para o desenho de processo e o protótipo a fase de análise encontra-se concluída em sua etapa mais formal.

Da fase de análise obtêm-se definições sobre como serão as fases seguintes:

• A partir das definições de análise é possível desenvolver um cronograma de execução
• A partir do cronograma e das necessidades do usuário é possível prever o pessoal que deverá ser envolvido nas fases seguintes do projeto (qtd. Desenvolvedores)
• A partir das informações acima é possível fazer uma previsão de custo do projeto e a partir desta informação a diretoria identifica sua real viabilidade.

Curiosidades sobre a etapa de análise

A etapa de análise na verdade não termina. Mesmo durante as etapas seguintes a análise continua a ocorrer,  se aprofundando mais tecnicamente no sistema. Eventualmente descobre-se na etapa de codificação novas características do negócio que alteram definições feitas em análise.

• O analista é, em geral, um gerente de projetos. Após a etapa de análise ele estará gerenciando os desenvolvedores na execução da especificação do sistema.
• O analista é em geral um já foi um desenvolvedor, mas que adquiriu um linguajar de negócios que permite que ele se comunique com os usuário na mesma língua destes, podendo desta forma extrair informações durante o levantamento.
• Quando desenvolvedor é comum que o analista não esteja 100% atualizado com as tecnologias atuais. 

Desta forma nem sempre o analista consegue realizar as melhores opções em termos de tecnologia para o projeto e, nos piores casos, o analista chega a ter dificuldade de falar com os desenvolvedores. Neste caso é necessária a presença de um outro personagem, o arquiteto do sistema, que tem por finalidade definir as tecnologias a serem aplicadas para execução do projeto, definir as metodologias de desenvolvimento a serem usadas pelos desenvolvedores e fazer a tradução entre o analista e os desenvolvedores quando necessário. 

A equipe de suporte deve trabalhar em conjunto do analista ou do arquiteto do projeto na definição física do projeto, iniciando uma especificação de equipamentos que serão necessários ao projeto.

Grande Abraço,

Gilberto Ribeiro.

O Propósito do Guia SCRUM - VIII

Por que usar SCRUM?

 

• O SCRUM não é um processo previsível, ele não define o que fazer em todas as circunstâncias (Ken Schuwaber, 2004)
• O SCRUM é super objetivo e simples, sua curva de aprendizagem é baixa, define papeis e responsabilidades de forma clara e consistente, no entanto, não é um processo previsível, é um processo empírico.
• O projeto é desenvolvido e entregue em partes menores, com constante feedback dos usuários.
• Os ciclos menores de desenvolvimento permitem um melhor gerenciamentos de riscos. O cliente avalia o software constantemente.
• A gestão das atividades é baseada no comprometimento e transparência da equipe. Reunião diária monitoram o andamento do projeto.
• O que é mais importante para o negócio (e não para área de TI) é entregue primeiro.
• Usuários estão envolvidos durante todo o ciclo de desenvolvimento e não somente no início e fim.
• As práticas da equipe evoluem constantemente por meio da aplicação de lições aprendidas frequentes.

Iterativo e Incremental

No SCRUM o desenvolvimento será iterativo e incremental. Construímos o software em partes, em incrementos. Estes incrementos são construídos em curtos períodos chamados de iteração. A cada iteração é feito um novo incremento, uma nova parte do software, até que o software fique totalmente completo.

Desenvolvimento Incremental

• Significa adicionar funcionalidades ou partes a cada vez de maneira incremental. É como adicionar tijolos a um muro. Depois de vários incrementos você tem um grande muro.

Desenvolvimento Iterativo

• Significa que nós construímos alguma coisa, depois a avaliamos em seguida fazemos alterações. Construímos algo esperando ter alterações. Nunca esperamos que algo saia perfeito na primeira vez.

Grande Abraço,

Gilberto Ribeiro.

Requisitos - XII

Desenvolvimento de Software

Não é raro em ambientes de desenvolvimento que muitos desenvolvedores sejam envolvidos em múltiplos projetos simultaneamente. Assim sendo ao mesmo tempo em que um desenvolvedor desenvolve dois softwares, está também corrigindo bugs de outros dois, dificultando desta forma o trabalho do desenvolvedor.

As tarefas de desenvolvimento, quer sejam elas de criação de novos softwares ou de manutenção dos softwares existentes, devem ser divididas em projetos e cada projeto deve seguir uma sequência de execução que garanta a qualidade do software que está sendo gerado.

Exemplo: Equipes Envolvidas

As seguintes equipes devem ser delineadas e envolvidas no processo de desenvolvimento:

• Desenvolvimento
• Testers
• Homologação
• Banco de Dados
• Suporte
• Produção

Divisões do Processo de Desenvolvimento

1. Análise (Requisito/Sistemas)
2. Codificação (Desenvolvimento)
3. Testes
4. Implantação
5. Produção 

Grande Abraço,
Gilberto Ribeiro.

O Propósito do Guia SCRUM - VII

Formação do conceito SCRUM

• Conversar mais para entender o domínio do negócio e escrever menos.
• Demonstrar constantemente o software para o cliente e obter feedback.
• O única certeza que temos em um projeto são as mudanças, requisitos mudam com frequência.
• Aprender com o domínio do negócio ao longo do ciclo de vida do projeto.
• A medida que aprendemos, ajustamos o produto.
• Mudanças são bem vindas.
• Desenvolvimento Incremental - Software é construído por partes.
• Desenvolvimento Iterativo - ciclos do desenvolvimento como: requisitos, análise, construção, teste e liberação.
• Times auto-organizáveis.
• Times multifuncionais.
• Envolvimento ativo dos usuários.
• Maximização do ROI.

Em 201 foi dado o grande pontapé para a grande disseminação das abordagem ágeis.

O Manifesto Ágil documentou os princípios orientadores para o desenvolvimento ágil e definiu uma filosofia em torno de um conjunto de metodologias existentes.

A base para o entendimento do SCRUM é o Manifesto Ágil e seus 12 princípios, se não os entendemos, não entendemos SCRUM.

Indivíduos e interação entre eles mais que processos e ferramentas.

Software em funcionamento mais que documentação abrangente.

Colaboração com o cliente mais que negociação de contratos.

Responder a mudanças mais que seguir um plano.

Os 12 princípios do Manifesto Ágil.

14. Qual é a maior prioridade dos 12 princípios do Manifesto Ágil?

• É satisfazer o cliente, por meio de entrega adiantada e contínua de software de valor.

15. Existe alguma restrição ou planejamento que contingencie as mudanças no projeto?

• Não, nós aceitamos mudanças de requisitos, mesmo no fim do desenvolvimento, para que o cliente obtenha vantagens competitivas.

16. O que significa desenvolvimento incremental?

• Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.

17. Com relação ao envolvimento de um especialista do negócio, qual a recomendação do SCRUM?

• Pessoas relacionadas à negócio e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.

18. Quais os fatores relacionados a equipe recomendado ao Scrum Master e ao Producr Owner pelo SCRUM?

• Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.

19. Como aumentar a agilidade nas equipes ágeis?

• Continua atenção à excelência técnica e bom design, aumentam a agilidade.

20. No SCRUM qual o método mais eficiente e eficaz de transmitir informações para, e por dentro de um time de desenvolvimento?

• É através de uma conversa cara a cara.

21.Qual a medida primária de progresso no SCRUM?

• Software funcional.

22. Como os processos ágeis promovem um ambiente sustentável?

• Mantendo passos constantes até o final do projeto, promovidos pelos patrocinadores, desenvolvedores e usuários.

23. Segundo o SCRUM o que é SIMPLICIDADE?

• É a arte de maximizar a quantidade de trabalho que não precisou ser feito.

24. Onde emergem as melhores arquiteturas, requisitos e design?

• De times auto-organizáveis.

25. Nos eventos SCRUM o sobre o que o time reflete?

• Em como ficar mais efetivo, ajustando e otimizando seu comportamento de acordo com o framework.

Grande Abraço,

Gilberto Ribeiro.

SCRUM - Implantação XIII

Os 12 Princípios Ágeis

1. Nossa maior prioridade é satisfazer o cliente, por meio da entrega adiantada e continua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento. Processos ágeis se adequam às mudanças, para que o cliente possa obter vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas até meses, com preferência aos períodos mais curtos.
4. Pessoas relacionadas à negócios e desenvolvedores devem trabalhar em conjunto e diariamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados. Dando a eles o ambiente e suporte necessário, e confiar que farão seu trabalho.
6. Contínua atenção à excelência técnica e com design, aumenta a agilidade.
7. O método mais eficiente e eficaz de transmitir informações para e por dentro de um time de desenvolvimento é através de uma conversa cara a cara.
8. Software funcional é a medida primária de progresso.
9. Processos ágeis promovem um ambiente sustentável. Os patrocinadores, desenvolvedores e usuários, devem ser capazes de manter indefinidamente, passos constantes.
10. Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto organizáveis.
12. Em intervalos regulares, o time reflete em como ficar efetivo, então, se ajustam e otimizam seu comportamento de acordo.

(http://manifestoagil.com.br)

Métrica de Software - XIII

Entidades Atributivas

É a entidade dependente que estende conceitualmente outra entidade, a entidade principal, descrevendo uma ou mais de suas características e cujas ocorrências podem substituir a repetição pode substituir a repetição de um mesmo subgrupo de dados em uma única ocorrência da principal, ou seja, a entidade INDEPENDENTE, principal, em conjunto com todas as entidades dependentes que a descrevem, são contadas como um único arquivos lógico.

Na contagem quando uma ocorrência da entidade principal puder existir se o respectivo par na entidade dependente deve-se contar dois tipos de registro, sendo a entidade principal e a entidade dependente. Quando OBIGATÓRIAMENTE para cada ocorrência da entidade principal houver necessidade de uma ocorrência da entidade dependente, ou seja, uma só tem sentido para o negócio acompanhada do preenchimento da outra, deve-se contar apenas um tipo de registro, compreendendo os tipos de dados de ambas as entidades.

Grande Abraço,

Gilberto Ribeiro.

Gestão de Projetos - XIII

Gerenciamento de projetos e gerenciamento de operações

As operações são uma função organizacional que realiza a execução contínua de atividades que produzem o mesmo produto ou fornecem um serviço repetitivo. Exemplos incluem: operações de produção, de fabricação e de contabilidade. Embora temporários em natureza, os projetos podem ajudar a atingir os objetivos organizacionais quando estão alinhados com a estratégia da organização. Às vezes, as organizações mudam suas operações, produtos ou sistemas pela criação de iniciativas estratégicas de negócios. Os projetos exigem um gerenciamento de projetos enquanto que as operações exigem gerenciamento de processos de negócios ou gerenciamento de operações. Os projetos podem cruzar com as operações em vários pontos durante o ciclo de vida do produto, tais como:

• Na fase de encerramento de cada um;
• No desenvolvimento ou atualização de um novo produto, ou ampliação de saídas;
• Na melhoria de operações ou do processo de desenvolvimento do produto ou
• Até a venda de ativos das operações no final do ciclo de vida do produto.

Em cada ponto, as entregas e o conhecimento são transferidos entre o projeto e as operações para implementação do trabalho entregue. Isso ocorre por meio da transferência de recursos do projeto para operações perto do término do mesmo ou pela transferência de recursos operacionais para o projeto no seu início.

As operações são esforços permanentes que geram saídas repetitivas, com recursos designados a realizar basicamente o mesmo conjunto de atividades, de acordo com as normas institucionalizadas no ciclo de vida de um produto. Diferente da natureza contínua das operações, os projetos são esforços temporários.

Grande Abraço,
Gilberto Ribeiro.

Fábrica de Software - XIII

Modelo de Estratégia de Implantação

A documentação da estratégia que irá guiar o planejamento do projeto pode conter, pela ordem, os seguintes itens:

1. Estrutura analítica do projeto – WBS – Work Breakdown Structure.
2. Alternativas de aquisição.
3. Ciclos de vida selecionados.
4. Estratégia de liberação de produtos.
5. Requisitos para o plano da qualidade.
6. Requisitos para o plano organizacional.
7. Requisitos para o plano de riscos.
8. Requisitos para o plano de comunicação.
9. Critérios para as estimativas.
10. Estratégia de envolvimento.
11. Necessidades de recursos.
12. Plano do planejamento.
13. Pontos de revisão do planejamento.
14. Estratégia de homologação.

Algumas sugestões práticas para a implementação de um projeto de Fábrica de Software são:

1. Selecionar um gerente de projeto com autoridade (formal e informal) e conhecimento dentro da empresa para ser o responsável pelo projeto.
2. Adotar uma abordagem incremental para a implantação da Fábrica (dificilmente se consegue implantar tudo de uma vez só).
3. Dar prioridade para:
1. •    A gestão da operação
2. •    A gestão de projeto
3. •    O processo de construção.
4. Implementar as ferramentas básicas para a automação da Fábrica, principalmente gestão de demanda.
5. Se for fazer o desenvolvimento interno de ferramentas de apoio, alocar recursos dedicados.
6. O projeto tem que ter um orçamento específico e deve haver comprometimento da empresa em seguir o planejamento.

Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - XIII

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)

Eficácia

“Capacidade do produto de software de permitir que usuários atinjam metas especificadas com acurácia e completitude, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Produtividade

“Capacidade do produto de software de permitir que seus usuários empreguem quantidade apropriada de recursos em relação à eficácia obtida, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Segurança

“Capacidade do produto de software de apresentar níveis aceitáveis de riscos de danos a pessoas, negócios, software, propriedades ou ao ambiente, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Satisfação

“Capacidade do produto de software de satisfazer usuários, em um contexto de uso especificado”. (NBR ISO/IEC 9126)

Grande Abraço,
Gilberto Ribeiro.

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.

Gestão de Projetos - XI

Projetos e planejamento estratégico

Os projetos são frequentemente utilizados como meio de atingir o plano estratégico de uma organização. Os projetos são normalmente autorizados como resultado de uma ou mais das seguintes considerações estratégicas:

• Demanda de mercado (por exemplo, uma companhia automobilística autorizando um projeto para fabricar carros mais econômicos em resposta à escassez de gasolina);
• Oportunidade/necessidade estratégica de negócios (por exemplo, uma empresa de treinamento autorizando um projeto para criar um novo curso a fim de aumentar a sua receita);
• Solicitação de cliente (por exemplo, uma companhia de energia elétrica autoriza um projeto de construção de uma nova subestação para atender a um novo parque industrial);
• Avanço tecnológico (por exemplo, uma empresa de produtos eletrônicos autoriza um novo projeto para desenvolver um laptop mais rápido, mais barato e menor após avanços obtidos em tecnologia para memória e circuitos eletrônicos de computador) e
• Requisito legal (por exemplo, um fabricante de produtos químicos autoriza um projeto para estabelecer diretrizes para o manuseio de um novo material tóxico).

Os projetos, em programas ou portfólios, são um meio de atingir metas e objetivos organizacionais, geralmente no contexto de um planejamento estratégico. Embora um grupo de projetos em um programa possa ter benefícios distintos, eles também podem contribuir para os benefícios do programa, para os objetivos do portfólio e para o plano estratégico da organização.

As organizações gerenciam portfólios com base em seu plano estratégico, o que pode ditar uma hierarquia para o portfólio, programa ou projetos envolvidos. Um objetivo do gerenciamento de portfólios é maximizar o valor do portfólio através do exame cuidadoso de seus componentes: os projetos e programas integrantes e outros trabalhos relacionados. Os componentes que contribuem menos para os objetivos estratégicos do portfólio podem ser excluídos. Dessa forma, o plano estratégico de uma organização torna-se o principal fator de orientação para investimentos em projetos. Ao mesmo tempo, os projetos fornecem feedback aos programas e portfólios através de relatórios de progresso e solicitações de mudanças que possam impactar outros projetos, programas ou portfólios. As necessidades dos projetos, incluindo as necessidades de recursos, são encaminhadas e comunicadas no nível do portfólio, o qual, por sua vez, determina a orientação para o planejamento organizacional.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - XI

Como modelar uma Fábrica de Software?

Planejamento - Fase 1

• Identificação do Modelo Organizacional.
• Definição do modelo de gestão e nível de maturidade. (CMMI - PMI/SCRUM)

Planejamento - Fase2

• Levantamento da estrutura onde a Fábrica será implantada.
• Levantamento da infraestrutura, instalações e equipamentos (estado da arte ou orçamento)

Planejamento - Fase3

1. Identificar os itens qualificados e ganhadores do pedido.
2. Determinar os objetivos de desempenho da operação.
• Determinar a estrutura organizacional.
• Determinar a infraestrutura operacional.
• Especificação da Fábrica.

A estratégia define:

• Como vamos estruturar a WBS dos produtos a serem entregues ao longo do projeto.
• Qual vai ser o ciclo de vida adotado para o projeto.
• Qual a melhor sequência das atividades em função das prioridades.
• Quem devemos envolver desde o início do projeto.
• Como os formadores de opinião vão ser envolvidos, e assim sucessivamente.

A estratégia depende também da complexidade do projeto, levando em consideração o seu porte e risco. O maior objetivo do planejamento estratégico é a redução da complexidade do projeto.

Grande Abraço,
Gilberto Ribeiro.