Posts Tagged ‘ planejamento

Não consigo obter uma descrição clara do que é Agile. Pode me ajudar? 26 July 2010 as 8:25 pm de Washington Souza

Pergunta: Vemos um monte de discussões sobre desenvolvimento Ágil e por vezes fanáticos se envolvem e acrescentam um monte de neblina a essas discussões, tornando o assunto mais nebuloso ainda.

O “Manifesto Ágil” explica um pouco mas não existe uma definição clara que possa ser usada para esta tag, ou seja, continua um mito para a maioria de nós. Eu, por exemplo, acredito que Agile é uma palavra qualitativa que não deve ser usada para definir uma metodologia.

Resposta: Não á espaço suficiente para escrever algo que dê um pouco de sentido sobre o assunto, há muita coisa, mas vamos tentar passar um pouco.

“Agile” é um termo genérico que se refere a um conjunto disperso de métodos que incluem SCRUM, XP, Feature Driven Development e outros modelos iterativos e incrementais. Você esta correto quando fala que “nao é uma metodologia em si”.

Você frequentemente ouve descrições muito soltas como “confiança”, “iterativo”, “sem documentação” (essa é a mais comum), etc. Estes são os termos mais comuns para se “falar” sobre Agile, todavia como podemos perceber, são bastante nebulosas. Para ser mais preciso:

1- Métodos Agile são iterativos, onde o ciclo de vida completo do projeto (planejamento, requisitos, design, testes, código) acontece em ciclos de tempo de menor duração, tipicamente 30 dias ou menos. Essas atividades são geralmente não lineares, mas empíricas, e nem sempre ocorrem em uma sequencia específica.

2- Métodos Agile são incrementais, onde um pequeno conjunto de requisitos é desenvolvido, seguido pelo refinamento ou outro conjunto de requisitos. Os métodos Agile são contra o “Big Bang” e defendem o desenvolvimento de pedaços menores de cada vez (Dividir para conquistar).

Leia o post completo →

+ Esqueci um requisito… e agora? Por Washington Souza 20 July 2010 as 12:01 am Nenhum comentário

O esquecimento de um “detalhe” (requisito) em projetos é mais comum do que se imagina. Normalmente alguém lembra: “Ops… faltou colocar isso no sistema… e agora?”. E o pior de tudo é que o mais comum é que isso aconteça próximo da entrega do sistema. Isto acontece normalmente por causa de um processo de especificação ineficaz ou até mesmo pela simples vergonha de perguntar um pouco mais de detalhe sobre um requisitos.

Quanto mais tarde se encontrar um defeito, mais caro ele será.

O gráfico abaixo é a melhor forma de se ilustrar isso:

Gráfico demonstrando o impacto de falhas no tempo do projeto

Repare que, quanto mais tarde, o custo vai aumentando exponencialmente, e este é um dos motivos que devem levar as empresas a investirem mais e mais em planejamento, controle e engenharia de software em geral.

Vamos a um cenário hipotético. Imagine que você esta fazendo um sistema que usa um índice para reajustar os custos de diversos produtos, este índice é praticamente o coração do sistema e você fez sua correção através do dolar. Porém, quando você começa a validar o mesmo com seu cliente você “descobre” que este índice deveria ser composto pela cotação do dolar, euro e mais quatro moedas. Qual impacto isto trará ao seu projeto? Bom… se você tivesse descoberto isto no início do projeto, o custo seria praticamente nulo, mas agora no final… imagine quanto você precisará gastar para ajustar este pequeno detalhe.

Quanto mais se investe em planejamento e especificação, menor será o tempo de desenvolvimento e você acabará montando mais do que desenvolvendo.

Enfim… pense nisso e aproveite e comente suas experiências em situações como esta.
Veja o post completo →

+ O que é timeline e como usa-lo? Por Washington Souza 18 July 2010 as 8:26 pm Nenhum comentário

O timeline (linha do tempo) é uma demonstração gráfica dos acontecimentos. É uma ferramenta muito boa para demonstrar os grandes marcos de um projeto ou acontecimentos. É muito usada pela astronomia, biologia, geologia e principalmente história, normalmente nestas áreas, o timeline é utilizado para demonstrar acontecimentos passados, mas ele também pode ser utilizado para demonstrar eventos futuros.

No gerenciamento de projetos, o timeline pode ser utilizado para demonstrar a equipe os principais marcos do projeto. Por ser uma ferramenta gráfica onde as pessoas conseguem facilmente entender seu funcionamento e ele é mais fácil de compreender do que o bom e velho cronograma.

Vamos mostrar como utlizar um timeline e responder duas perguntas, a primeira é “o que é um timeline?” e a segunda é “Como implementar o CMMI 2?”

Em um timeline sempre colocamos os marcos (milestones) em uma ordem cronológica e estes marcos deve ter nomes de fácil compreensão. Você até pode explicar um elemento em um timeline, mas ai seria um outro tipo (diferente deste que vou mostrar).

Nosso exemplo trata de uma implementação CMMI 2 e tipicamente, este tipo de implementação leva 12 meses e contém estes marcos:

  • Gap Analisys
  • Planejamento
  • Capacitação
  • Processos & áreas
  • Templates & Guias
  • Revisão e ajustes
  • Data de corte
  • Novo processo
  • SCAMPI B
  • Ajustes
  • SCAMPI A

Então, o seu timeline seria assim:

timeline para implementação do cmmi 2

Veja o post completo →

+ O que faz um projeto fracassar? Por Washington Souza 22 June 2010 as 5:00 am Nenhum comentário

Um projeto exige muito esforço de muitas partes para alcançar o sucesso procurado. Tamanho esforço aplicado sempre deixa implícita uma questão: será que esse esforço todo levará o projeto ao sucesso nos resultados?

Na tentativa de estreitar o caminho que leva ao sucesso nos projetos, foram verificadas as direções mais comuns que levam ao seu inssucesso, tendo essas, portanto, que serem evitadas a todo custo. São elas:

Objetivos não definidos
Sem um escopo claro e consistente, o projeto perde em direção, dinâmica e, principalmente em fundamento, pois não vê definição final no que procura. O objetivo é o que alimentará todo o empenho da equipe, do gerente e dos stakeholders na busca pelo sucesso nos resultados.

Implementação mais lenta que o planejado
A dinâmica com que se apresentam os resultados do projeto é um termômetro de como a logística de distribuição das tarefas e o acompanhamento e controle das atividades estão em sintonia. A implementação anda na medida em que critérios como o conhecimento das potencialidades individuais e coletivas da equipe é conhecido e utilizado de forma adequada ao que propõe o planejamento do projeto.

Recursos insuficientes
Muitas vezes, a escassez de recursos é vista de forma tão forte como um problema que se esquece de vê-la como um desafio a vencer. Os recursos surgem sempre para a melhor utilização possível dentro do planejamento do projeto, no momento e métrica suficientes, para obtenção dos resultados ideais que justifiquem seu uso.

Surgimento de problemas não previstos
A prática faz crer que é improvável para um projeto caminhar sempre nos trilhos. Assim, o gerente precisa ficar atento para desvios inesperados, sempre com uma capacidade de gerar soluções na medida das necessidades e respeitando fatores preponderantes como prioridades, tempo de resposta, bem como riscos e consequências das soluções sugeridas. Quando um projeto é bem planejado e estruturado, fica menos sujeito a instabilidades causadas por imprevistos, mas, nem por isso, há garantias de que algo fora do esperado não possa acontecer.

Coordenação ineficaz de atividades
Uma equipe mau orientada pode ser classificada injustamente como limitada ou algo semelhante, quando, na verdade, a fonte de seu fracasso está em quem direciona seus passos, define suas ações e acompanha seus resultados. Da mesma forma, um projeto mau planejado, um risco mau avaliado, um prazo mau medido podem determinar um caminho mais curto e indesejado a projetos. A coordenação do projeto como um todo se descreve como sua coluna vertebral, de onde saem análises, pontos de vista, indicações, expertise e de onde as fraquezas gerenciais devem ser anuladas e ampliadas a todo tempo.

Veja o post completo →

+ Entendendo a Gerência de Configuração Por Washington Souza 21 June 2010 as 9:04 pm Nenhum comentário

Uma coisa é certa em todos os projetos: “as coisas mudam”. Os requisitos podem mudar, o usuário pode melhorar seu entendimento sobre um determinado requisito e solicitar mudanças. O ambiente pode mudar, novas leis podem fazer com que o sistema mude e até mesmo a troca do usuário pode fazer com que as coisas mudem. Com tantas mudanças, se nada for feito o sistema pode naufragar. Para isto, tanto o CMMI quanto o MPS.Br possuem uma área de processo para endereçar este assunto, a Gerência de Configuração.

A gerência de configuração (GC) é um conjunto de atividades que permite as mudanças no projeto de forma controlada, mantendo a estabilidade no decorrer do mesmo.

A gerência de configuração é extremamente importante em um projeto, é por isso que diversos modelos de qualidade e maturidade como ISO, CMMI, MPS.Br e SPICE dão tanto valor à esta disciplina.

O CMMI define que GC deve:

  • Identificar os produtos que serão mantidos sob controle de configuração
    Normalmente são mantidos os principais produtos de um projeto como documentos de proposta, planejamento, cronograma, especificações, código e outros.
    .
  • Definir um sistema de gestão de configuração
    Um sistema de gestão vai desde o processo até a definição de uma ferramenta de configuração, uma boa ferramenta de gestão pode economizar muito trabalho no processo de gerenciamento de configuração, o Sharepoint é bom no gerenciamento de configuração de documentos, mas não atende bem a parte de código. O código por sua vez é muito bem controlado no SVN e este por sua vez não se da muito bem com documentos, mas existem mais de 50 ferramentas com este propósito.
    .
  • Manter seus baselines
    O baseline é uma versão de um produto ou conjunto de produtos. Se toda a parte de requisitos do módulo de gestão já esta aprovada, pode-se gerar um baseline destes produtos e caso seja necessária alguma alteração, muda-se a versão do baseline (após passar por todo o processo).
    .
  • Acompanhar e controlar as solicitações de mudanças
    Este é o principal motivo da existência da gerência de configuração. Mudanças vem de toda parte, desde o usuário até a sua equipe, e estas mudanças devem passar por um processo de viabilidade, análise de impacto e aprovação formal. Todas as mudanças devem ser documentadas e de fácil acesso.
    .
  • Registrar todas as alterações realizadas nos produtos
    Uma vez realizada uma alteração em um produto, esta deve ser documentada e colocada novamente em baseline (após aprovação). Uma boa prática é descrever a alteração sempre que um produto for movimentado.
    .
  • Veja o post completo →

+ Dez mitos sobre as práticas genéricas Por Washington Souza 14 June 2010 as 10:34 pm Nenhum comentário

Antes de iniciarmos, temos que ter em mente que as práticas genéricas são elementos mandatários do CMMI e seu objetivo central é a institucionalização, mas… o que é institucionalização?

O CMMI define como institucionalização: “A maneira de se fazer negócios que uma organização segue rotineiramente como parte de sua cultura corporativa”. Em outras palavras, o jeito que as coisas são feitas aqui.

Diversos elementos podem atrapalhar a implementação das práticas genéricas como menosprezar a importância da institucionalização, foco apenas nas práticas específicas ou até mesmo sub-estimar o tempo e esforço necessário para sua implementação.

Vamos falar da Generic Goal 2:

  • GP 2.1 Estabelecer uma política organizacional
  • GP 2.2 Planejar o processo
  • GP 2.3 Prover recursos
  • GP 2.4 Atribuir responsabilidades
  • GP 2.5 Treinar as pessoas
  • GP 2.6 Gerenciar configurações
  • GP 2.7 Identificar e envolver stakeholders relevantes
  • GP 2.8 Monitorar e controlar o processo
  • GP 2.9 Analisar aderência objetivamente
  • GP 2.10 Revisar o status com a alta direção

Mitos sobre práticas genéricas

GP 2.1 Mito 1: “Tudo que precisamos fazer é escrever algumas políticas e pedir para o CIO assina-las”

  • As políticas podem virar um papel que nunca ninguém irá ler
  • As políticas devem definir claramente o que deve ser feito
  • Se as políticas documentarem o que a alta gerência realmente acredita ser importante, as chances delas serem seguidas aumentam considerávelmente.

GP 2.2 Mito 2 “Um plano para cada área de processo”

  • O perigo dos infinitos planos “Aqui esta o plano para coletar as métricas de PPQA”
  • O planejamento apropriado deve ser realizado para cada área de processo envolvido
  • Garantir tempo, esforço e custo suficiente para executar as tarefas necessárias para realizar cada processo

GP 2.3 Mito 3: “Esta prática e apenas para garantir que teremos pessoas suficientes”

  • O risco de focar apenas em pessoas: “Nunca teremos pessoas suficientes”
  • Recursos INCLUEM custo, instalações, ferramentas e obviamente pessoas
  • “Recursos adequados” quer dizer que o processo pode ser seguido naturalmente sem restrições de custo, prazo ou pessoas

GP 2.4 Mito 4: “As pessoas não precisam da descrição de seu serviço”

  • Não assuma que as pessoas compreenderam suas responsabilidades e nível de autoridade
  • Defina claramente papéis e responsabilidades que alinhem as pessoas ao serviço realizado
  • Faça as pessoas compreenderem seus papel e defina a autoridade necessária para realizar seu trabalho

Veja o post completo →

+ A diferença entre chefe e líder Por Washington Souza 28 May 2010 as 12:01 am 2 comentários

Há tempos, definiu-se como líder, aquela pessoa que tem seguidores atraídos pelo carisma e confiança. Um chefe por sua vez, tem autoridade única e exclusivamente pelo cargo que detém. Desta forma, podemos dizer que todo líder tem completas condições de ser um chefe, mas temos que refletir se: E o contrário, é possível?

Chefiar é buscar resultados, planejar os trabalhos das pessoas, organizar, priorizar, manter e controlar. Estas nada mais são que  funções básicas, porém, hoje em dia, para chefirar também é necessário motivar as pessoas. Com uma equipe motivada consegue-se melhores resultados e um clima melhor (e nem preciso dizer que reduz o custo e aumenta a produtividade).

Ser chefe é bem mais fácil pois o poder conferido ao cargo por sí é o aparato necessário. O líder, por outro lado, deve se preocupar em conduzir as pessoas, dar um significado ao trabalho e convencer os liderados a defender sua causa.

Diferentemente das épocas anteriores, hoje as pessoas escolhem onde querem trabalhar. As pessoas da Geração Y, não se prendem mais a uma empresa, logo, se não estiverem satisfeitas em seu local de trabalho trocarão tão fácil quanto trocam de roupa. E… com o mercado aquecido, provavelmente elas não ficarão um dia sequer desempregadas. Isso deveria ser motivo suficiente para as empresas preferirem ter líderes e não chefes.

Hoje, todo chefe tem o discurso de líder na ponta da língua, é um discurso bonito, e todos gostam de ouvir, porém suas ações lhe dirão se ele é realmente um líder. Talvéz a até tenha mudado a forma de pensar, mas não a de agir e isto leva tempo.

Um líder é aquele que mesmo sem autoridade alguma consegue ser seguido, respeitado e obedecido. Ele consegue unir um grupo, representa-lo e leva-lo a atingir objetivos.

Chefiar é fazer com que as pessoas façam algo.
Liderar é fazer com que as pessoas queiram fazer algo.

Assim, podemos ver várias diferenças entre chefes e líderes como:
Veja o post completo →

+ 15 dicas sobre gestão (e como decidir melhor) Por Francisco Silva 13 December 2009 as 8:25 pm 1 comentário

  1. Não suponha. Pergunte
  2. Não acredite cegamente… Verifique
  3. Analise os fatos sobre dados de fonte conhecida (e confiável). Conheça o histórico
  4. Utilizar cases como forma de decidir melhor
  5. Lembre-se que não dá para fazer um omelete sem quebrar os ovos
  6. Não prometa além de sua competência
  7. Use de referências. Crie paradigmas
  8. Não jogue com 100%
  9. Tenha sempre um plano B (para usa-lo quando necessário)
  10. Separe o crítico do importante. Inicie rápido pelo crítico
  11. Analise sempre os custos antes de tomar uma decisão
  12. Utilize indicadores históricos e de tendências
  13. Analise os impactos de mudanças
  14. Acredite mais do que os números te dizem do que o que as pessoas te dizem
  15. Faça isto rápido e decida. Acompanhe a decisão e corrija rotas

Veja o post completo →

+ Tutorial mini projeto – O nascimento da idéia Por Washington Souza 07 December 2009 as 11:08 pm 2 comentários

Prólogo

O objetivo deste mini-tutorial é mostrar como se inicia um projeto.
Para facilitar o entendimento (e disseminar conhecimento) ele é focado na simplicidade, facilitando assim o entendimento.

A estimativa de tamanho em APF toma por base que todos os elementos são de complexidade média, todavia é importante vocês terem em mente que isto é apenas o início. Em se interessando procurem ler mais sobre estimativa, planejamento, desenvolvimento de requisitos e controle de mudanças – aos que estão iniciando com MPS.BR ou CMMI, este tutorial vai ajudar bastante nos primeiros níveis.

Tutorial Mini Projeto – O nascimento da idéia

Um amigo te liga e pede para você fazer uma visita pois ele precisa de um projeto, ele te fala que é bem simples e precisa apenas de um aplicativo para gerenciar seus contatos.

Chegando em seu escritório, a conversa começa e ele fala que tem mais de 1.000 contatos em uma agenda (papel mesmo) e que quer (e precisa) automatizar isso. Na sua cabeça você já percebe que terá uma tela (até agora).

Conversa vai, conversa vem, ele comenta que um grande problema que ele tem é que ele não consegue dizer de onde são os contatos. Ele comenta que se ele pudesse agrupar-los, isso o ajudaria muito.

Ele também comenta que gostaria que tudo ficasse em uma única tela, ele não gosta de ficar passeando de uma tela pra outra.

Veja o post completo →

+ O que é produtividade? Por Washington Souza 10 November 2009 as 8:46 pm Nenhum comentário

Hoje se fala muito em produtividade, mas não são muitos o que realmente entendem o que é produtividade.
Se você chegar a um departamento de TI e pedir (como exemplo) uma lista classificada dos programadores mais produtivos, é quase certo que você não a terá. Isto acontece porque são poucas as empresas que realmente medem a produtividade de suas equipes, e isto ocorrerá em 90% dos casos.

A produtividade consiste em o que é produzido em um determinado tempo.

Em linhas de produção isso é mais tranqüilo, pois você consegue “ver”, “pegar” e “contar”. Fica mais fácil de comparar. Mas… e quando falamos de software?
Primeiramente, vamos a algumas perguntas:

  • Qual a produtividade de sua equipe?
  • Quais os 10 programadores mais produtivos?
  • O que você faria para entregar dentro do prazo um projeto crítico com uma parede*?
    *Parede: Data onde o sistema precisa necessariamente estar online, sob pena de multa.

Se você hesitou em responder a primeira pergunta, você acaba de descobrir uma excelente oportunidade para conhecer como sua equipe trabalha de fato. Isto será muito importante nas suas estimativas e especial no seu planejamento e venda.

Se você não consegue responder a segunda pergunta, ou a responde baseado em sua percepção (e não em números), é bom refletir e medir isto, o ganho será assustadoramente compensador.

Já a terceira pergunta… para respondê-la você DEVE ter feito a lição de casa das duas primeiras perguntas. Muitas empresas colocam os melhores programadores para ter certeza que vão entregar e assim, não pagar a multa. Bom… este é um bom caso de gestão de riscos, mas, você pode provavelmente economizar um bom dinheiro se simplesmente conhecer a produtividade de sua equipe, e assim, deslocar as pessoas certas para o projeto.

Veja o post completo →

+ Analisando o custo x benefício em um projeto Por Washington Souza 31 August 2009 as 3:22 am Nenhum comentário

Uma das principais responsabilidades de um gerente de projetos é zelar pelo custo do projeto e usar este dinheiro da melhor forma possível (Leia o PMI para mais detalhes).

Apesar disto ser (vamos dizer) óbvio, não são muitos os gerentes que fazem uma boa gestão do custo, e, durante o planejamento do projeto o gerente do projeto deve analisar tudo o que deve ser feito e fazer uma análise de custo x benefício .

Se você tem 10.000 para fazer uma determinada coisa, e existe um “componente” que faz exatamente o que você quer por menos da metade do preço, porque não adquiri-lo? Bom, é muito provável que você já deva ter presenciado uma situação assim, e é mais provável ainda que a decisão tenha sido de “fazer” o requisito, perdendo assim uma excelente oportunidade para economizar.

Outro caso é: Em um sistema onde você o usuário se cadastra e escolhe seu estado a pergunta é: Será desenvolvido uma tela de manutenção de estados?

Cenário 1: Sim, o cliente precisa atualizar a lista de estados sempre que precisar – Custo: R$ 1.000,00 (referente à 20 horas de trabalho)

Cenário 2: Não, é uma tabela que raramente muda, o custo não justifica o benefício – Custo: R$ 0,00

É um caso simples, mas neste caso simples você já economizou um montante do seu custo. Claro que existirão casos onde estes desenvolvimentos serão necessários, todavia serão minoria e mesmo nestas minorias, provavelmente a contratação de um serviço (como o de CEP dos correios) saia mais em conta.

Uma dica: Pratique esta análise durante o planejamento. Provavelmente você terá boas surpresas.

+ Top 10 dicas para administração de tempo Por Washington Souza 05 June 2009 as 1:28 am 5 comentários

mulher feliz administração de tempoPessoal, gostaria de dar algumas dicas para melhoria na administração de tempo e em no próximo post vou explicar como é óbvio o link destas dicas com o planejamento e gerenciamento de projetos

1. Tenha um planejamento diário do que você deve fazer

Não precisa ser nada muito complexo, uma lista simples em uma agenda, folha ou até mesmo online já resolve. Coloque todas as atividades que você deve fazer naquele dia e defina prioridades. É importante começar pelas atividades mais críticas.
Conforme o dia for passando, monitore se você esta atendendo os prazos que você definiu e tome ações quando estiver atrasado.
Após algum tempo procure mudar a frequência deste planejamento para semanal.

2. Defina objetivos

Tenha claro quais são seus objetivos de curto (semana) médio (mês) e longo (3 meses) prazo. Imprima (ou anote) e deixe sempre a vista (assim você não esquece). Avalie também se o que você vai fazer agrega algum valor, se não agrega, provavelmente você não deve perder tempo com isto.

3. Saiba dizer não

Você não receberá nenhum crédito por aceitar fazer “mais uma coisinha” quando esta atolado de coisas, muito pelo contrário, se você atrasar as importantes ai que ninguém se lembrará mesmo. Se há algum risco de atraso por causa de uma nova tarefa, deixe isto bem claro e não assuma este risco sozinho.

4. Seja organizado

Se você iniciou uma coisa, termine-a. Muitas pessoas iniciam muitas coisas ao mesmo tempo mas nunca terminam nenhuma. Se você esta adiando muitas das tarefas do seu planejamento diário, quer dizer que você não esta organizando seu tempo tão bem quando planejado. Divida as tarefas grandes em “pedaços” menores que você consiga controla-las em um dia.
Muito se usa o termo “seja acabativo” que nada mais é do que “termine o que você iniciou”.

5. Saiba delegar

Você não deve fazer tudo, aliás, nem é bom. Como gestor você deve delegar para os responsáveis e quando necessário treinar as pessoas para assumirem uma nova responsabilidade. Todavia tenha certeza de que as pessoas estão aptas a cumprir as tarefas. Lembre-se que o responsável ainda é você.
Veja o post completo →