Perfil Profissional - I

Tenho recebido e-mails solicitando informações sobre o perfil ideal na contratação de um profissional de TI. 

Bom, não existe um perfil ótimo e definitivo, mesmo porque o mercado está em constante evolução e constantemente precisamos participar de cursos de especializações para reciclarmos nosso conhecimento. As certificações são fundamentais, pois atestam o conhecimento teórico do profissional, ele precisa dominar os conceitos básicos de qualquer profissão, mas não podemos abrir mão da prática, da experiência. 

Para a empresa contratante o perfil ideal é aquele que se adequa ou está alinhado com seus objetivos estratégicos.

Com base no ciclo de vida do projeto, organizei perfis que servirão de base para adequação das empresas contratante e de norte para os profissionais da área de TI.

Mas antes falarei um pouquinho sobre o envolvimento dos profissionais nas fases do projeto na Engenharia de Software, com base no PMI, e isso servirá de base para a elaboração do perfil na hora da contratação.

Elicitação de requisitos em alto nível

Elicitação de Requisitos Funcionais e Não Funcionais

Identificação de Risco e Restrições

Refinamento de Requisitos

Aprovação de Requisitos

Criar Matriz de Rastreabilidade

Diagrama de Casos de Uso

Atualização do Glossário do Projeto

Métrica de Software - I

O que é a Análise e Ponto de Função?

A Análise de Ponto de Função (APF) é uma técnica de medição das funcionalidades fornecidas por um software do ponto de vista de seu usuário. Ponto de Função é a unidade de medida desta técnica que tem por objetivo tornar a medição independente da tecnologia utilizada para a construção do software. Ou seja, a AFP busca medir o que o software faz, e não como ele foi construído.

O processo de medição, ou a imagem de pontos de função, baseia-se em uma avaliação padronizada dos requisitos lógicos do usuário.

Empiricamente as principais técnicas de estimativas de projetos de desenvolvimento de software assumem que o trabalho de um software é um vetor importante para a determinação do esforço para sua construção. Logo, saber o seu tamanho é um dos primeiros passos do processo de estimativa de esforço, prazo e custo.

É importante destacar que pontos de função não medem diretamente esforço, produtividade ou custo. É exclusivamente uma medida de tamanho funcional do software. Este tamanho em conjunto com outras variáveis é que pode ser usado para derivar produtivamente, estimar esforço e custo.


Grande Abraço,
Gilberto Ribeiro.

Engenharia de Software - I

Ohno, criador do Sistema Toyota de Produção, escreveu “existe algo chamado trabalho padrão, mas padrões devem ser alterados constantemente. Se você considera o padrão como o melhor que pode fazer, não há avanço”, Ohno prossegue dizendo que, se estabelecermos algo como a “melhor maneira possível, a motivação do kaizen [melhoria contínua incremental] deixará de existir” (1982).

Extraído do Livro Desenvolvimento de Software com SCRUM,

Aplicando Métodos Ágeis com Sucesso.

Grande Abraço,
Gilberto Ribeiro.

O Propósito do Guia SCRUM - I

Esta série é direcionada não somente para os futuros candidatos ao exame Professional Scrum Master, mas para todos que desejam entender o propósito do Guia SCRUM.

Durante o exame devemos responder questões sobre:

• Scrum básico 
• O que é e o que ele envolve?
• Teoria do Scrum 
• Por que o Scrum funciona e quais são os seus princípios? Do que ele difere dos modelos tradicionais de desenvolvimento?
• O framework Scrum e seus eventos/cerimônias 
• Como o Scrum é realizado utilizando papéis, eventos time-boxes, artefatos e regras.
• Scrum e mudanças 
• Como o Scrum lida com as mudanças?
• Time Scrum 
• Como se organiza, quais seus princípios e como formá-los?
• Planejamento Scrum 
• Planejar um projeto e estimar seu custo e data de término.

SCRUM

É uma estrutura processual ou framework para suportar o desenvolvimento ou manter produtos complexos.

Define:

• Papéis
• Eventos                  
• Artefatos
• e Regras que os unem os papéis, eventos e artefatos, mantendo-os integrados.

Estatísticas da Standish Group, Chaos Manifesto 2011, estudo sobre a taxa de sucesso dos projetos.

Atendimento a expectativas

• 37% atendem as expectativas iniciais.
• 42% dos sistemas não funcionam como planejado ou nunca serão usados.
• 21% fracassaram totalmente.

Qualidade

•  57% dos sistemas são entregues sabendo-se que tem defeito.

Prazos

• 68% dos projetos são entregues com atrasos 

Custos 

• 50% dos projetos custam mais do que o planejado.

Visão Geral do SCRUM

O cliente assume o papel de coautor do sistema, na figura do Product Owner, e tem a liberdade de solicitar o que ele deseja e quando ele desejar. No SCRUM as mudanças são sempre bem vindas, e facilitada pela equipe de desenvolvimento, pois fazem parte do processo de desenvolvimento.

O SCRUM é um framework onde as pessoas podem tratar e resolver problemas complexos e adaptativos, de forma produtiva e criativa entregam produtos com o mais alto valor para o negócio do cliente.

Questões sobre o framework SCRUM

1. Quais as características do framework SCRUM?

• Leve.
• Simples de Entender.
• Extremamente difícil de dominar.

O SCRUM é um framework estrutural que esta sendo usado para gerenciar o desenvolvimento de produtos complexos desde o início de 1990.

2. O que o SCRUM não é?

• Um processo ou uma técnica para construir produtos.

3. O que o SCRUM é?

• Um FRAMEWORK dentro do qual podemos empregar processos e técnicas.

4. O que o SCRUM torna claro?

• A eficácia relativa das práticas de gerenciamento e desenvolvimento de produto, de modo que você possa melhorá-las.

5. O que garante o sucesso do framework SCRUM?

• O respeito a sua essência que é formada por: PAPÉIS, EVENTOS, ARTEFATOS E REGRAS, cada um com seu propósito específico.

6. Qual a função das regras do SCRUM?

• Integrar os papéis, os eventos e artefatos, administrando as relações e interações entre eles.

7. Como o SCRUM está fundamentado?

• Nas teorias empíricas de controle de processos, ou empirismo.

O empirismo afirma que o conhecimento vem da experiência e de tomada de decisão baseada no que é conhecido.

8. Para aperfeiçoar a previsibilidade e o controle de risco, qual a abordagem que o SCRUM usa?

• ITERATIVA e INCREMENTAL

Grande Abraço,
Gilberto Ribeiro.

Gestão de Projetos - I

O Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK®) é uma norma reconhecida para a profissão de gerenciamento de projetos. Um padrão é um documento formal que descreve normas, métodos, processos e práticas estabelecidas. Assim como em outras profissões como advocacia, medicina e contabilidade, o conhecimento contido nesse padrão evoluiu a partir das boas práticas reconhecidas de profissionais de gerenciamento de projetos que contribuíram para o seu desenvolvimento.

O Guia PMBOK® fornece diretrizes para o gerenciamento de projetos individuais. Ele define o gerenciamento e os conceitos relacionados e descreve o ciclo de vida do gerenciamento de projetos e os processos relacionados.

Grande Abraço,

Gilberto Ribeiro.

Fábrica de Software - I

Como estabelecer uma operação de software mais efetiva em termos de custo, agregação de valor ao negócio, qualidade, previsibilidade do atendimento aos serviços de desenvolvimentos e manutenção? Por onde começar o processo de implantação de gestão e de operação na área de TI? (Em especial na área de desenvolvimento de sistemas)

A falta do conhecimento gera o caos no mercado, profissionais se apaixonam por termos novos e que estão na moda e pregam, sem conhecimento de causa, processos que leram em algum lugar, sem aos menos terminar o texto na integra, e defendem seu ponto de vista particular como doutores no assunto. Oportunista que prometem a “bala de prata” para solucionar todos os problemas relacionados à gestão e operação na área de TI.

Vendem o peixe como entenderam e geralmente para quem não domina o assunto, ou seja, tudo o que ele fala soa como verdade.

O que entendemos sobre Fábrica de Software? Qual o nosso nível de maturidade sobre o assunto, será que basta reutilizar componentes desenvolvidos em outros projetos para usarmos o termo Fábrica de Software, ou isto seria apenas o antigo conceito reutilização, que é uma pequena parte que compõe o todo complexo, e que está relacionada à operação de TI.

Uma Fabrica de Software vai além dos conceitos simplórios e de domínio público, porém para atendermos as suas expectativas precisamos da visão orientada para Gestão de Operações.

Não podemos entender uma revendedora de peças de automóvel como uma fábrica de peças, nem a segunda como uma fábrica de veículos. 

Outro ponto polemico é a utilização de boas práticas, baseadas em modelos de qualidade consagrados, mas que sem o conhecimento da gestão de operações de várias demandas e projetos e seus requisitos, não produzem os resultados esperados. Atribuo aqui à falta de conhecimento na implantação dos processos na Fábrica de Software.

Nosso maior desafio neste novo cenário será aprender a manter a Fábrica de Software (ou Fábrica de Serviços) de forma regular e consistente ao longo do tempo, gerindo operações de software em larga escala e todas as suas variáveis e elementos que as  fundamentam.

Uma vez absorvido todos os conceitos sobre a Fábrica de Software, vamos expandir nosso horizontes para nichos de mercado como offshore, que tem como objetivo a prestação de serviço para as empresas globalizadas e também como implementar uma plataforma de exportação de serviços de programação e desenvolvimento de software.

Nos próximos textos faremos uma viagem conceitual formando a base, os pilares da Fábrica de Software.

“Vamos dividir para conquistar”.

Grande Abraço,
Gilberto Ribeiro.

Requisitos - II

Os requisitos são o ponto de partida para toda a definição de um sistema e, consequentemente, são fatores decisivos no desenvolvimento do produto final de um projeto de software.

Toda metodologia de desenvolvimento de software ou processo de desenvolvimento de software propõe uma série de fases e atividades dentro do seu ciclo de vida e o encadeamento entre elas.

Independente do nome dado a cada fase, é extremamente recomendado que o processo contemple ao menos dois grandes grupo de atividades referentes a requisitos, que poderíamos chamar de:

Engenharia de requisitos

São todas as atividades realizadas para:

• Identificar
• Analisar
• Especificar
• Definir

as  necessidades do negócio que um aplicativo deve prover para a solução do problema levantado. Requisitos que não refletem as reais necessidades dos usuários, incompletos e/ou inconsistentes, mudanças de requisitos que já foram previamente acordadas e dificuldades para chegar a um acordo entre profissionais de TI e usuários são os maiores problemas enfrentados no grupo de atividades de especificação de requisitos.

Gestão de requisitos

Preocupa-se com a:

• Documentação
• Versionamento
• Controle de mudanças
• Qualidade dos requisitos levantados na fase de especificação de requisitos.

Todos os requisitos apresentam um ciclo de vida único que acompanha a dinâmica dos negócios associados. Assim sendo não se pode esperar que um requisito seja imutável ao longo do tempo, uma vez que o negócio do qual o requisito se desprende é dinâmico.

Mas o que é REQUISITO?

Os requisitos expressam as características e restrições do produto de software do ponto de vista de satisfação das necessidades do usuários e, em geral, independem da tecnologia empregada na construção da solução, sendo a parte mais crítica e propensa a erros no desenvolvimento de software.

Um conjunto de requisitos pode ser definido como uma condição ou capacidade necessária que o software deve possuir para que o usuário possa resolver um problema ou atingir um objetivo ou para atender as necessidades ou restrições da organização ou dos outros componentes do sistema.

Grande Abraço,

Gilberto Ribeiro.