Fernando Costa

Para quem gostava do Atari, uma nova oportunidade, Dealextreme!

Roberto Marinho dos Santos, PMP – rob.marinho@terra.com.br

Todos nós já ouvimos que o mercado é competitivo e sabemos que uma das consequências disso é a pressão por resultados, que são buscados geralmente na forma de projetos, e por sua vez são fundamentados em um tripé composto por escopo, custo e tempo, esse último, o tempo é o item que vamos abordar, procurando trazer luz a uma questão bem específica, principalmente no contexto de projetos de desenvolvimento de software, que é a de mensuração de prazos.

Formular prazos é algo que temos que lidar quase que diariamente, seja para uma atividade nova dentro de um projeto em que estamos participando, seja uma manutenção, ou diversos outros cenários em que nos vemos tendo que estimar prazos, e isso é algo que muitas vezes nos deixa desconfortáveis e apreensivos, pois nem sempre estamos seguros de estarmos informando o prazo suficiente ou exagerando na estimativa. Daí uma série de questionamentos se torna necessária: Como formulamos os prazos que fornecemos ? Quais são as ferramentas e técnicas que usamos para mensurar o prazo de uma atividade ? Simplesmente temos usado a famosa adivinhação, que consiste em “vou chutar e multiplicar por dois” ?.

A boa notícia é que existem formas de obter prazos mais precisos, com ferramentas e técnicas que podem ser usadas para obtenção dessas estimativas, e algumas delas são:

Opinião especializada, consiste em uma estimativa que pode se basear em informações históricas de outros projetos ou em opinião de especialistas, como por exemplo, consultar pessoas que possuem grande conhecimento específico em frameworks ou aplicativos que serão usados na atividade.

Estimativa análoga, significa usar a duração real de uma atividade anterior semelhante, como base para a estimativa da duração de uma futura atividade do cronograma, usada para estimar a duração quando existe uma quantidade limitada de informações detalhadas sobre a atividade. Pode também usar informações de projetos anteriores. A estimativa análoga da duração é mais confiável quando as atividades anteriores são verdadeiramente, e não apenas aparentemente semelhantes, e os membros da equipe que preparam as estimativas possuem a especialização necessária.

Estimativa paramétrica, uma estimativa de duração da atividade pode ser construída usando uma média das três durações estimadas. Muitas vezes essa média irá fornecer uma estimativa de duração da atividade mais exata do que a estimativa mais provável de um único ponto. Os três durações são:

Mais provável. A duração da atividade quando fornecidos os recursos com mais probabilidade de serem atribuídos, sua produtividade, as expectativas realistas de disponibilidade para a atividade do cronograma, as dependências de outros participantes e as interrupções.

Otimista. A duração da atividade se baseia em um cenário para o melhor caso

do que está descrito na estimativa mais provável.

Pessimista. A duração da atividade se baseia em um cenário para o pior caso do

que está descrito na estimativa mais provável.

Pontos de função, não poderia deixar de citar essa que é uma medida funcional de tamanho de software, introduzida em 1979 pela IBM, é realizada com base em cinco tipos de componentes de software: arquivos internos, arquivos externos, entradas, saídas e consultas. Embora tenha muitos críticos, por esses entenderem que essa técnica está ultrapassada, ainda encontra espaço no mercado e existem exemplos de seu uso demonstrando que essa ainda pode ser usada como apoio à estimativa de prazo.

Outro ponto a destacar é quanto a necessidade de abolir reservas não identificadas (tempo extra no prazo), que são usadas como garantia, e para isso é necessário uma mudança comportamental que deve começar e ser estimulada pelos gestores da equipe, que devem encorajar aqueles que vão fazer as estimativas a não incluir essas reservas nos prazos. Possíveis riscos e situações que possam gerar atraso identificados durante essas estimativas, devem ser registrados e reportados para que sirvam de apoio à previsão de reservas identificadas, criteriosas e de conhecimento de todos.

Concluindo, a expectativa aqui é estimular uma reflexão sobre as possibilidades na estimativas dos prazos e despertar o interesse sobre as técnicas para um possível aprofundamento, e porque não o seu efetivo uso, mesmo que de forma gradual mas consistente. Tenho certeza que os resultados valerão o esforço.

Referências Bibliográficas

International Function Point Users’ Group (IFPUG) – www.ifpug.org

Um Guia do Conjunto de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK®) Terceira edição

2004 Project Management Institute.

Fonte: http://robertomarinhosantos.blogspot.com/

A V.OFFICE, parceira Globalcode em Santa Catarina, traz para Florianópolis o Evento Open TDC, cujo objetivo é apresentar tendências, tais como o desenvolvimento para TV Digital!

O objetivo do Open TDC é promover junto à comunidade acadêmica palestras sobre assuntos indispensáveis para qualquer profissional Java tais como EJB, JSF, SOA e UML. Com apoio do Grupo de Usuários GUJAVA este Evento pretende também apresentar tendências, como o desenvolvimento para TV Digital. PARTICIPE!

O evento acontecerá no dia 15 de agosto de 2009, no auditório do FECOMÉRCIO- Federação do Comércio do Estado de Sta.Catarina que fica localizado na Rua Felipe Schmidt, 785 – centro – Florianópolis – SC.

Fonte: Open TDC

http://computerworld.uol.com.br/negocios/2009/04/20/aquisicao-da-sun-coloca-a-oracle-no-centro-do-mercado-de-hardware/

Eu, eu, eu, MySQL se deu mal?

O Vicente postou no Twitter este link com aulas de Python gratuitas.

A proposta:

Você quer aprender uma linguagem de programação nova? Está afim de automatizar algumas funções do computador? E que tal uma linguagem simples e poderosa? Que tal uma linguagem que pode começar com simples scripts e se tornar até programas em GTK? Gostou da idéia? Então você está pronto(a) para começar a aprender Python!

O curso me pareceu bem caprichado, se quiser experimentar acesse: http://infog.casoft.info/

“Oi pessoal,

Segue uma coletânea de itens do livro, o objetivo é mostrar que o livro é bom e vale a pena ser lido.

1) Os ativos da empresa não eram apenas os seus produtos, mas também seus funcionários.

2) Uma das principais estratégias de negocio de Jobs em toda a sua carreira tem sido recrutar as pessoas mais talentosas que puder encontrar.

3) A organização é limpa, simples de se entender, e as responsabilidades estão bem definidas. Tudo fica mais simples. Este tem sido um dos meus mantras – foco e simplicidade.

4) Um dos mantras favoritos de Jobs na Apple é: “Foco significa dizer não”.

5) Mantenha o foco: não de margem ao excesso de funções. Mantenha as coisas simples, o que é uma virtude em um mundo de tecnologia excessivamente complexa.

6) Se alguma coisa for muito difícil de usar, Jobs dá instruções para que seja simplificada. Qualquer coisa que seja desnecessária ou confusa deverá ser removida.

7) As pessoas não sabem o que querem. Como disse certa vez Henry Ford: “Se eu perguntasse a meus compradores o que eles queriam, teriam respondido que era cavalos mais rápidos”.

Patrick Whitney, diretor do Instituto de Design de Tecnologia de Illinois, a maior faculdade de design dos Estados Unidos, disse que os grupos de usuários não são adequados à inovação tecnológica.

9) Muitas vezes as pessoas só sabem o que querem depois que você mostra a elas.

10) Como disse o escultor romeno Constantion Brancusi: “Simplicidade é a complexidade resolvida.”

11) Reduzir e reduzir acabou se tornando um exercício, mas isto torna mais fácil a construção, e, para as pessoas, torna mais fácil trabalhar.

12) Inclua todo mundo: O design não é só para designers. Engenheiros, programadores e profissionais de marketing podem ajudar a descobrir como um produto funciona.

13) Jobs é um elitista que acredita que uma pequena equipe nota 10 é muito mais eficiente do que exércitos de engenheiros e designers.

14) Contratar apenas empregados absolutamente geniais e demitir as antas tem sido um dos mais constantes princípios gerenciais de Jobs.

15) As vezes ele diz: ‘Acho que precisamos fazer isto’ – é um teste para ver se alguém irá desafiá-lo. São pessoas deste tipo que ele está procurando.

16) Ele quer parceiros que critiquem suas idéias, e cujas idéias possam ser criticadas por ele, muitas vezes vigorosamente.

17) O segredo de Jobs: não tem importância ser um idiota, contando que você seja apaixonado pelo que você faz.

18) A inovação não tem nada a ver com a quantidade de dólares que você investe em P&D. Quando a Apple lançou o Mac, a IBM estava gastando no mínimo cem vezes mais em P&D. Não é uma questão de dinheiro. É a equipe que você tem, sua motivação e o quanto você entende da coisa.

19) Você precisa de uma cultura muito orientada para produtos, até numa empresa de tecnologia. Muitas empresas têm toneladas de grandes engenheiros e de gente inteligente. Mas é preciso que, no fim, haja alguma coisa que puxe tudo ao mesmo tempo.

20) Criatividade é apenas conectar as coisas.

Abraços a todos,

Abu”

Fonte: blogdoabu.blogspot.com

Ouro Preto / MG – 04 de junho de 2009

Introdução

O II Workshop de Gerenciamento de Projetos de Software (WGPS) ocorrerá no escopo das atividades do VIII Simpósio Brasileiro de Qualidade de Software (SBQS 2009) e será, a exemplo do ano anterior, um fórum dedicado à apresentação dos resultados obtidos com a aplicação do Gerenciamento de Projetos no contexto de Tecnologia da Informação. O objetivo deste workshop é compartilhar conhecimento de técnicas, ferramentas, métodos e relatos de experiências de Gerenciamento de Projetos no segmento de Tecnologia da Informação, mostrando os resultados obtidos e as lições aprendidas. Pretende-se ainda estimular a integração e a cooperação de pesquisadores nesta área, com empresas e entidades que apóiam, oferecem serviços, ferramentas ou utilizam conceitos de Gerenciamento de Projetos nas suas organizações.

Datas importantes

- Prazo de submissão de relatos de experiência: 31/03/2009 (NOVA DATA)

- Notificação aos autores: 26/04/2009

- Entrega da versão final (camera-ready): 03/05/2009

- Entrega do material de apresentação (slides): 23/05/2009

Tópicos de interesse

Os temas de interesse do WGPS 2008 incluem relatos de experiências que revelem exemplos da aplicação de boas práticas de Gerenciamento de Projetos na área de Tecnologia da Informação, mais especificamente em software, sem, no entanto, se limitar a eles:

- Casos de Projetos bem sucedidos

- Lições Aprendidas em Projetos mal sucedidos

- Gerenciamento Ágil de Projetos

- Ferramentas de Gerenciamento de Projetos

- Análise de Viabilidade de Projetos

- Gerenciamento de Projetos no Contexto do CMMI e MPS-BR

- Garantia da Qualidade em Software

- Gerenciamento de Desenvolvimento de Produtos em Software

- Métricas de Software

- Gerenciamento de Riscos

- Comunicação em Projetos

- Corrente Crítica

- Gestão de Mudanças em Projetos de Software

- Gerência de Portfólio de Projetos

Submissão dos trabalhos

Prazo para submissão: 31/03/2009

Todos os trabalhos submetidos serão avaliados pelos membros do Comitê de Programa, formado por especialistas na área de Gerenciamento de Projetos. Os artigos devem obrigatoriamente atender aos seguintes critérios, todos eliminatórios:

- Seguir rigorosamente as instruções de formatação

- Não possuir qualquer tipo de Marketing de fornecedores ou produtos

- Apresentar resultados práticos

- Possuir relevância para a comunidade de Gerenciamento de Projetos, especialmente na área de Tecnologia da Informação

- Possuir atratividade para o público presente no WGPS

Os trabalhos selecionados deverão ser apresentados pelos autores durante o Workshop e serão publicados nos anais do evento. A submissão ao II WGPS deve ser feita através de um relato de experiência descrevendo e analisando a aplicação de processos, métodos ou ferramentas de gerenciamento de projetos, contextualizando a experiência e mostrando os resultados obtidos e lições aprendidas, em um caso prático, com contribuição para a indústria de software.

Os trabalhos devem ser submetidos diretamente de forma eletrônica pelo sistema JEMS, utilizando a seguinte página: https://submissoes.sbc.org.br/sbqs2009

Com relação ao formato, pede-se observar os requisitos a seguir, que são todos obrigatórios. O relato de experiência deve:- ser escrito em português ou inglês- ter entre 4 e 6 páginas, incluindo todas as figuras, referências e apêndices- seguir o formato definido pela SBC (Sociedade Brasileira de Computação), disponível em http://www.sbc.org.br, indo até a aba “Eventos”, janela “Arquivos” (à esquerda), item “Template para publicação de artigos”.- ser enviado no formato Adobe Portable Document Format (PDF) .

Coordenação

Dra. Sheila Reinehr

Email: sheila.reinehr@pucpr.br

Era uma vez… um anúncio de emprego:

“Vaga: Estagiário de Sistemas/ Estagiário de Desenvolvimento
Requisitos:
- Formação superior em andamento na área de informática
- Inglês técnico
- Prática em programação web e teste de software

Conhecimentos desejáveis:
- Programação desktop
- Conhecimentos sobre webservices e xml
- UML, RUP e XP

Irá atuar em todas as fases do desenvolvimento de software: modelagem de negócios, análise de requisitos, projeto de software, implementação (principalmente), teste de software e implantação. Além de atuar na manutenção dos sistemas auais e suporte ao usuário.”

Esse pode parecer um anúncio de emprego do tipo Caracu, na qual o empregador entra com a cara e o candidato com o complemento. Mas nele se esconde, o princípio Euquipe.

A vantagem da área de tecnologia na área de empregos é que pode-se começar a trabalhar muito cedo. Aprende-se a programar sozinho, com alguma boa vontade, internet e/ou livros e muitas horas sentado escrevendo códigos, testando algoritmos, etc.

A questão é que desenvolvimento de software profissional deixou de ser uma atividade solitária de software e virou uma cadeia produtiva com especializações em diversas áreas e o conjunto delas é conhecido como Engenharia de Software. Da mesma forma que a Engenharia tradicional diversificou-se entre Civil, Mecânica, Elétrica, etc. A profissão ainda é nova e há uma enorme confusão até mesmo dentro do meio acadêmico.

O que é Engenharia de Software?

São um grupo de áreas de conhecimento que definem como criar e entregar software. De acordo com o IEEE Computer Society Software Engineering Body of Knowledge (SWEBOK), a lista de de Áreas de Conhecimento (KA ou Knowledge Area) é composta por:

• Software requirements
• Software design
• Software construction
• Software testing
• Software maintenance
• Software configuration management
• Software engineering management
• Software engineering process
• Software engineering tools and methods
• Software quality

Então imagine o super-estagiário que os canalhas acima querem laçar. Se traçarmos um paralelo com medicina, eles querem um: cirurgião geral, com especialização em neurologia, pneumologia, hematologia, barba, cabelo e bigode (depilar mulheres é um plus).

A culpa não é do RH das empresas, mas da cultura corporativa industrial: minimizar com a “mão de obra”. Em tecnologia é um das maiores fontes de gasto, mas também, a única geradora de renda, através de solução de problemas e inovação. Os profissionais resolvem um problema e se expressam em ferramentas, scripts, programas de computador, diagramas, documentos, planilhas, apresentações. Ou seja, você precisa de cérebros capazes de tratar, interpretar e apresentar informação, não apertadores de botões.

Para de enrolar Bicalho, o que é o Princípio Euquipe?

1. Princípio Euquipe é quando uma empresa ou prestador de serviço resolve economizar todo o processo de produção de software em cima de um único profissional. Todas as responsabilidades, do levantamento de requisitos, implementação, testes e homologação, manutenção e implantação, ficam sob os ombros de uma única pessoa.

É a sabotagem de um projeto antes mesmo de iniciado e uma atitude de mau caratismo. Tanta importância delegada a um único indivíduo não é motivo de comemoração. É a velha mania de terceirização da culpa, o “tirar da reta” para depois dizer: O fracasso do projeto foi porque o(a) Euquipe da Silva é um(a)  incompetente. Tudo estava sob responsabilidade dele(a) e deixou o projeto afundar.

E quem estava responsável pelo trabalho do profissional? Dessa pergunta, vem a segunda definição do Princípio Euquipe:

2. Ninguém é incompetente sozinho.

“Tudo o que é preciso para o mal prevalecer são os bons não fazerem nada.” (Edmund Burke)

Fonte:
Meiobit

Bicalho’s Memory About Fraked Up Jobs, Websites de Emprego, SWEBOK