Mostrando postagens com marcador Qualidade. Mostrar todas as postagens
Mostrando postagens com marcador Qualidade. Mostrar todas as postagens

sexta-feira, fevereiro 13, 2015

Gerenciamento de Projetos

Sobre o Gerenciamento de Projetos




Estou as voltas com uma matéria de muito apreço que pude ter contato em meu curso de pós graduação e em alguns anos conduzindo projetos de TI, o Gerenciamento de Projetos.
Durante este ano de 2015 muito provavelmente terei novos desafios envolvendo o tema. Aproveito o momento oportuno para usar este espaço para criar algumas postagens sobre esse assunto tão importante para a maioria das empresas, sejam públicas ou privadas.

Este primeiro post vou tentar resumir de forma bem geral o que entendo como Gerencia de Projetos, como guia uso as referências do livro de boas práticas, o principal livro de referência do PMI o PMBook versão 5.

A necessidade da gerencia de projeto nasce justamente da premissa do controle, da gestão, do acompanhamento, da estruturação de um plano e do que acontece durante sua execução, monitorando sistematicamente cada fase e em fim registrando o seu encerramento.
Ou seja, basicamente 5 grandes grupos de atividades:
1 – Iniciação
Onde o projeto é posto à prova, sobre o ponto de vista de viabilidade, descrevendo em um documento chamado Termo de Abertura os objetivos do projeto, um cronograma inicial e principais fontes motivadoras de sua existência, nesta fase também são identificados todos os envolvidos ou interessados no projeto.
2 – Planejamento
A fase de planejamento é basicamente onde o projeto será idealizado, onde nasce o plano de gerenciamento do escopo, cronograma, EAP etc., é onde se define todas as regras para serem usadas durante a execução do projeto, é definido como será tocado o projeto dos pontos de vista de Escopo, Tempo, Custos, Riscos, Qualidade, Recursos humanos e Comunicações.
3 – Execução
A fase de Execução é como o nome diz, pôr em prática tudo o que foi planejado. As equipes são mobilizadas, a qualidade é apurada, as aquisições são conduzidas, a equipe se desenvolve, a comunicação acontece de forma frequente e o próprio planejamento pode ser ajustado com base no andamento da execução.
4 – Monitoramento e Controle
Esta fase basicamente acompanha a execução e define se uma mudança no planejamento pode acontece e como vai acontecer, controlando o cronograma, o escopo, o trabalho, controla a comunicação, controla os riscos, aquisições e até mesmo o engajamento das partes interessadas.
5- Encerramento

Muitas vezes é onde a grande engrenagem é iniciada, pois como todo projeto se compõe de início, meio e fim, ao final do projeto podemos ter um produto finalizado ou transição para o início das atividades de um serviço de produção. Na fase de encerramento também se documentada as lições aprendidas e a conclusão de serviços contratados nas fases de aquisição.

sexta-feira, janeiro 27, 2012

Resumo do livro Clean Code

Resumo de alguns tópicos do livro Clean Code do Uncle Bob, recomendadíssimo!
programador profissional é aquele que produz código limpo e testado!
 Regra de escoteiro: “você deve sempre deixar o lugar mais limpo do que encontrou” 

Nomes significativos

Nomes de classes, variáveis, métodos, etc, devem ser significativos, indicando claramente o que um método faz ou o que um atributo representa. A intenção deve ser visível através dos nomes. Crie nomes pronunciáveis para facilitar a comunicação, evite acrônimos e siglas.
Evite nomes confusos, os quais podem levar quem lê o código a conclusões erradas.
Use nomes que refletem o domínio do sistema, o contexto e os problemas que devem ser resolvidos.

Funções

Funções devem ser pequenas. Aliás, elas devem ser ainda menores. Deve haver apenas um nível de abstração por função.
Funções devem fazer uma coisa, e apenas uma. Novamente, utilize um nome que descreva bem o que a função faz. Utilize o menor número de argumentos possível, fazendo o máximo para que não passem de três.
Cuidado com “efeitos colaterais”, funções não podem fazer nada “escondido”. Use exceções ao invés de códigos de erro, e considere que tratar exceções é uma coisa.

Comentários

Comentários não salvam um código ruim. Procure explicar o que o código faz COM CÓDIGO.
Crie nomes de métodos e de variáveis informativos, ao invés de explicar com um comentário o que um método com um nome ruim faz. Use comentários para deixar uma expressão complexa mais clara, para avisar sobre as possíveis conseqüências de uma alteração, ou para ressaltar a importância de certo ponto do código.
Comentários ruins também poluem o código. Não escreva comentários redundantes, inúteis, ou pior, com falsas informações. Também não deve ser usado para indicar quando ou por quem foi alterado, para isso temos ferramentas de controle de versão. Não escreva comentários confusos ou grandes demais.
Não comente código que não será mais usado, simplesmente remova-o.

Objetos e estruturas de dados

Siga a Lei de Demeter. Faça boa abstração e encapsulamento. Não crie objetos burros.

Tratamento de erro

Use exceções ao invés de códigos de erro. Use exceções não checadas, e utilize mensagens de erro informativas.
Não retorne e nem passe null.

Testes

Siga as 3 leis do TDD.
Use uma assertiva por teste, e teste um conceito por vez.
Os testes devem ser rápidos, independentes, reprodutíveis em qualquer ambiente, auto-validáveis e escritos no momento certo. Mantenha o código de seus testes limpo.

Classes

Classes devem ser pequenas e seguir o princípio da responsabilidade única. Devem ser coesas,  essa coesão resulta em classes pequenas. Classes devem ser criadas visando a mudança, então programe orientado à interface.
Outros pontos que não posso deixar de citar são: Todos os testes devem estar passando; refatoração deve ser feita constantemente, visando à melhoria contínua; código duplicado deve ser evitado a todo custo; classes e métodos devem ser pequenos; o código deve ser o mais expressivo possível.
Esse resumo é um levantamento de alguns pontos importantes, tanto que aqui é mostrado o que deve ser feito, não o porquê ou o como, isso pode ser encontrado no livro. Esse post é o primeiro passo, espero que todos dêem continuidade lendo esse livro e muitos outros, buscando criar um código melhor. Eu não quero mais código sujo atrapalhando a minha vida. E você?
(Resumo feito  por Juliano Alves)

sexta-feira, novembro 27, 2009

Beneficios do processo de requisito de alta qualidade

Organizações que implementam engenharia de requisitos de forma efetiva podem garantir muitos benefícios. A grande recompensa vem da redução do retrabalho desnecessário nos estágios finais de desenvolvimento e ao longo do período de manutenção prolongada. O benefício da alta qualidade de requisitos as vezes não é muito obvia, e muitas pessoas acreditam erroneamente que o tempo gasto discutindo requisitos simplesmente vai gerar atraso na entrega do produto.


Ninguém pode prometer corretamente o ROI na aplicação de um processo de requisitos de alta qualidade. Pensando de forma analítica, da para imaginar como a aplicação de um processo bem feito de engenharia de requisitos pode ser benéfico. Primeiro, considere o custo de investir em um melhor processo. Isso inclui o custo da avaliação de suas práticas atuais, desenvolver novos processos e modelos de documentos, capacitação da equipe, compra de livros e ferramentas, e talvez a contratação de consultores externos. Seu maior investimento é o tempo de suas equipes demoram para coletar, documentar, analisar e gerenciar as suas exigências.
Em seguida, basta pensar sobre os possíveis benefícios que você possa desfrutar e quanto tempo ou dinheiro é possível economizar. É impossível quantificar todos os benefícios, mas estes são alguns:

  • Menos defeitos nos requisitos
  • Redução do retrabalho de desenvolvimento
  • Redução de funcionalidades desnecessárias
  • Menor esforço
  • Desenvolvimento mais rápido
  • Redução na falha de comunicação
  • Redução do estouro do escopo do projeto (scope creep)
  • Reduzir o caos no projeto
  • Maior satisfação dos clientes e membro da equipe

terça-feira, janeiro 20, 2009

Requisitos de Software

Estou abrindo com este post uma serie de estudos sobre analise e engenharia de requisitos, tenho certeza que será de grande proveito para quem pensa em fazer a coisa certa antes de refazer a coisa toda heheheh.
Inicialmente pretendo segui os seguintes tópicos:

O básico sobre Requisito de Software
  • Definindo Requisito de Software
  • Algumas interpretações sobre "Requisitos"
  • Tipos de Requisitos, O que não é Requisito
  • Desenvolvimento e Gerenciamento de Requisitos
  • Todo projeto tem Requisitos
  • Quando Requisitos ruins acontecem para pessoas boas
  • Benefícios do Processo de Requisitos de Alta qualidade
  • Características de Requisitos Excelentes