quarta-feira, 30 de dezembro de 2009

Uma excelente reflexão sobre lider

Um artigo do Manoel Pimental na InfoQ que trata de assuntos sobre “você seria liderado por si mesmo?”  e  motivação e emoção.

Outras perguntas reflexivas “você contrataria a si mesmo?”

Vale pena ler http://www.infoq.com/br/articles/voce-seria-liderado-por-si-mesmo

Reflexões sábias para próximo ano de 2010.

Fonte: http://www.infoq.com/br/articles/voce-seria-liderado-por-si-mesmo

Bye see you next post

ThoughtWorks Coding Dojo em janeiro de 2010 na FACIN, PUC-RS

Em 20 de janeiro teremos Pair Programming, TDD and BDD na

FACIN, PUC-RS.

Mais informações:http://codingdojo.tw/?p=20

Bye see you next post

sexta-feira, 18 de dezembro de 2009

Padrões para Introduzir Novas Ideias

Padrões para Introduzir Novas Ideias from Locaweb on Vimeo.

Padrões Para Introduzir
Novas Ideias na Indústria de Software
Patterns for Introducing New Ideas

Apoio
Locaweb
Agilcoop
Agradecimentos
Fabio Kon

Defesa de dissertação de mestrado em Ciência da Computação e apresentada no dia 11/05/2009 no Instituto de Matemática e Estatística da Universidade de São Paulo
(IME-USP)

Baseado no roteiro original de
Linda Rising e Mary Linn Manns

Bye see you next post

Refactoring vs. Rewrite

Refactoring vs. Rewrite

Posted using ShareThis

Gerenciamento Ágil de Projetos e Scrum 1 de 2 - Ricardo Viana Vargas, MSc, IPMA-B, PMP | Macrosolutions

Gerenciamento Ágil de Projetos e Scrum 1 de 2 - Ricardo Viana Vargas, MSc, IPMA-B, PMP Macrosolutions

terça-feira, 15 de dezembro de 2009

Cursos de Verão no IME-USP 2010

Serão ministrados três cursos no Verão Ágil 2010. O Treinamento contará com professores membros da AgilCoop no IME/USP.

Três cursos serão oferecidos:

Introdução a Métodos Ágeis de Desenvolvimento de Software

Desenvolvimento de Software de Qualidade através de Testes Automatizados

Laboratório de Programação eXtrema

Mais informações: http://ccsl.ime.usp.br/agilcoop/node/97

Fonte:http://ccsl.ime.usp.br/agilcoop/

Bye see you next post

BDD & DDD

Uma apresentação publicada pela infoq sobre BDD & DDD.

O Apresentador é Dan North um dos principais consultores da ThoughtWorks.

http://www.infoq.com/presentations/bdd-and-ddd

Bye see you next post

terça-feira, 8 de dezembro de 2009

Software para gerenciar o seu Product Backlog

Na Lista scrum-brasil o colega José Alexandre D'Abruzzo Pereira deu sugestões de softwares para gerenciar Product Backlog que são:

O custo dos softwares são baixos.

Nas ferramentas free temos as seguintes:

Colaboração do colega Anderson Clayton para scrum-brasil.

Colaboração de André Faria Gomes.

Se preferir poderá usar um quadro ou planilha. O que importa é conhecer os benefícios do gerenciamento do Product Backlog e frutos que poderá colher durante cada interação.

Fonte: lista scrum-brasil@yahoogrupos.com.br

Bye see you next post

quarta-feira, 2 de dezembro de 2009

Evento AgileDay em Porto Alegre – material criado por Flávio Steffens de Castro

Descrição, fotos e vídeos do Evento AgileDay em Porto Alegre em 1/12/2009, material criado por Flávio Steffens de Castro. Vale a pena conferir:

http://www.agileway.com.br/2009/12/02/agileday-em-porto-alegre-como-foi/#more-521

Bye see you next post

terça-feira, 1 de dezembro de 2009

Coding Dojo

Daniel Cukier explica os conceitos básicos do coding dojo.

Baseados nos slides do Hugo Corbucci e Danilo Sato.

Fonte:www.youtube.com/watch?v=E-jFKkaAc7k

Bye see you next post

Documentação Ágil – Vinicius Teles

Documentação Ágil from Vinicius Teles on Vimeo.

Fonte:http://vimeo.com/1450383

Bye see you next post

segunda-feira, 30 de novembro de 2009

Uma breve introdução sobre Lean em 4 minutos : Tratando mais da filosofia

Fonte: www.youtube.com/watch?v=FsKghWVmyQo

Bye see you next post

2 anos de agilidade na Globo.com

2 anos de agilidade na Globo.com from Igor Macaubas on Vimeo.

A palestra de Igor Macaúbas(Scrum Master da Globo.com) no Ágiles 2009 em Florianópolis/SC.

Os assuntos da palestra foram os principais desafios em manter a cultura ágil viva, o que deu certo, o que não deu certo e os desafios atuais.

Bye see you next post

sexta-feira, 27 de novembro de 2009

Porto Alegre Agile Day 2009

Em 1º de Dezembro de 2009 de acontecerá o evento Porto Alegre Agile Day 2009 na PUCRS.

Evento contará com os seguintes palestrantes:

Vinicius Teles  da ImproveIT – Palestra Negócios ágeis

Eduardo Meira Peres da DBServer – Palestra Linha Ágil: Integração de Disciplina e Agilidade em uma Organização CMMI nível 2

Carlos Vilella da ThoughtWorks – Palestra Integração e Entrega Contínua

Manoel Pimentel Medeiros da InfoQ / Visão Ágil – Palestra Coaching e Facilitação

Realização de GUMA e Spin-POA.

Mais informações:

http://agileday2009.guma-rs.org/

Visite o site e participe. Vale a pena.

Bye see you next post

quarta-feira, 25 de novembro de 2009

Pomodoro: Interrupções Ilustradas

É um capitulo cedido para avaliação sobre interrupções do livro Pomodoro Technique Illustrated: The Easy Way to Do More in Less Time do autor Staffan Nöteberg.

http://media.pragprog.com/titles/snfocus/interrupt.pdf

O livro para compra http://www.pomodoro-book.com/

Bye see you next post

domingo, 22 de novembro de 2009

Hoje é dia de pomodoro

Palestra feita por Adolfo Sousa mostrando como organizar o dia-a-dia focando nas tarefas importantes.

 Hoje é dia de pomodoro from Locaweb on Vimeo.

Fonte: http://vimeo.com/6122566

Bye see you next post

quinta-feira, 19 de novembro de 2009

Ágiles 2009: resumo do evento

Ágiles 2009: resumo do evento from Bluesoft on Vimeo.

Luiz Faias Jr. apresentou a equipe um resumo dos pontos mais importante Ágiles 2009 em Florianópolis.

Parabéns pela iniciativa e divulgação.

Fonte:http://vimeo.com/7687800

Bye see you next post

Manifesto Ágil e Princípios: A base para começar na agilidade

Já trabalhei com muitos softwares utilizando o modelo cascata. Muitos projetos deram certo, mas quase sempre com prorrogamento de prazo.

Vivemos numa sociedade que tem uma grande demanda de softwares complexos e heterogênicos, sistemas distribuídos ou não e as requisições são mutáveis. Nada é constante.

Os métodos tradicionais tem os seguintes problemas:

  • Se baseiam em prever o futuro, dai pergunto: Como saber o que vai acontecer daqui um ano? Temos estimativas e não certezas;
  • Não há muita interação com cliente. Geralmente analista de negócios tem pouca comunicação com cliente. Levanta requisitos para construção do projeto e depois anda sem muita comunicação com cliente. Inclusive o próprio cliente deseja o produto pronto e não quer se envolver no projeto;
  • Burocracia: documentações excessivas, processos, controles e etc.;
  • Progresso do projeto é baseado no crescimento da burocracia e não no código.

Problemas com software:

  • Muitos erros. A desenvolvimento geralmente não é orientado a testes(faltam testes-TDD);
  • Pouca flexibilidade.

Soluções:

  • Melhorar a tecnologia: Práticas de padrões de projeto, reutilizar código e abstração.
  • Métodos Ágeis
  • Melhorar a comunicação e colaboração do pessoal do negócios e time 

Manifesto Ágil foi iniciado por programadores e consultores experientes que questionavam práticas tradicionais da Engenharia do Software e Gerencia de Projetos.

Assinatura do manifesto foi feita por 17 desenvolvedores em Utah - fevereiro de 2001.  Os 17 desenvolvedores são:

Kent Beck
Mike Beedle
Arie van Bennekum
Alistair Cockburn
Ward Cunningham
Martin Fowler
James Grenning
Jim Highsmith
Andrew Hunt
Ron Jeffries
Jon Kern
Brian Marick
Robert C. Martin
Steve Mellor
Ken Schwaber
Jeff Sutherland
Dave Thomas

http://agilemanifesto.org

Valores do Manifesto Ágil:

  • Os indivíduos e suas interações estão acima de procedimentos e ferramentas;
  • O funcionamento do software esta acima de documentação completa;
  • A colaboração dos clientes esta acima de contratos;
  • Adaptação a mudança.

Princípios do Manifesto Ágil:

  • A priori é satisfazer o cliente entregando rapidamente e de forma contínua software com valor(funcionando corretamente);
  • Entregar versões funcionais em prazos curtos:semanalmente, quinzenalmente ou meses(não recomendável);
  • Requisitos mutáveis;
  • As pessoas relacionadas aos negócios e desenvolvedores devem trabalhar juntas diariamente durante todo projeto;
  • Comunicação direta(cara a cara);
  • Medida do processo é feita através de software em funcionamento;
  • Desenvolvimento sustentável.
  • Motivação do time do projeto;
  • Simplicidade: a arte de maximizar a quantidade de trabalho que não precisou ser feito;
  • Cuidados com excelência técnica e bom design aumenta a agilidade;
  • As melhores arquiteturas, requisitos e designs emergem de times auto-organizáveis.
  • Num intervalo de tempo regular, o time faz uma analise de como melhorar eficiência e ajusta o comportamento para tal objetivo;

Fonte: http://www.manifestoagil.com.br/principios.html

e http://agilcoop.org.br/

Bye see you next post

domingo, 15 de novembro de 2009

domingo, 8 de novembro de 2009

Scrum e XP direto das Trincheiras - Livro para download

Download é gratuito, mas é necessário o cadastramento de um usuário no site da infoq.

http://www.infoq.com/br/minibooks/scrum-xp-from-the-trenches

Este livro inclui:

  • Dicas práticas  e truques para a maioria das práticas de Scrum e XP;
  • Armadilhas típicas e como elas devem ser trabalhadas;
  • Diagramas e fotos ilustrando o dia-a-dia;
  • Testes;
  • Escalar e coordenar múltiplos times;
  • Lidar com resistência de dentro ou de fora do time;
  • Técnicas de planejamento e estimativa.

Prefácios por Jeff Sutherland e Mike Cohn

148 Páginas, ISBN: 978-1-4303-2264-1

Henrik Kniberg é consultor na Crisp em Estocolmo (http://www.crisp.se), especializando em Java e desenvolvimento ágil de software. Ele fundou várias empresas suecas de software e é apaixonado por aprender, ensinar e aplicar a arte do desenvolvimento de software. Henrik tem uma abordagem holística e gosta de exercer diferentes papéis como gerente, desenvolvedor, scrum master, professor e coach. Para mais informações veja http://www.crisp.se/henrik.kniberg.

Bye see you next post

Painel: Agilidade no dia a dia

Em 2008 correu o evento de lançamento do InfoQ Brasil. Esse painel aborda assuntos como: Projetos Ágeis não falham? Quais são os critérios para definir o sucesso de um projeto? Por que escolher agile? Confira!
http://www.infoq.com/br/presentations/painel-agile
Obs.: Fizeram uma pequena analogia com anos 90 e agilidade. Tipo: voltamos aos anos 90.

Fonte: http://www.infoq.com/br/presentations/painel-agile


Bye see you next post

segunda-feira, 26 de outubro de 2009

Implantando a Cultura Ágil no Ambiente de TI



Através de experiências com XP e estudos dos métodos ágeis em empresas, fiz uma analise de como implantar a cultura ágil no ambiente de TI.

Tanto numa fábrica de software ou empresa que não adote o modelo fábrica de software a cultura cascata geralmente esta em funcionamento. O modelo cascata tem origem de projetos da construção civil e difere da produção de software, portanto o modelo cascata não seria totalmente apropriado para produção de software.

O Software sofre mudança até quando já esta pronto, já um prédio depois de pronto não pode ser movido de leste para sul. Imagine ter quer cortar um andar depois de pronto, seria impossível.

O modelo cascata foi adequado a produção de software, mas nada impede do modelo cascata ser usado com métodos ágeis, aliás convém dizer que alguns equipes utilizam métodos ágeis e cascata e outras equipes utilizam somente métodos ágeis.

O importante num ambiente de fábrica de software ou empresa é não impor para equipes a cultura ágil e sim convencer. Como pode ser feito isto? Cursos da cultura ágil para todos os envolvidos e depois workshops no trabalho para colocar na veia a cultura ágil.

Muitas empresas que começaram a cultura ágil e não proporcionaram cursos no inicio, tiveram dificuldades na implantação da cultura ágil.

Saliento que não estou falando inverdade quando digo que uma fabrica de software pode aplicar cultura ágil, já vi várias fábricas usando métodos ágeis e com sucesso.

Mas imagine um ambiente silencioso não ágil tipo uma fabrica de software ou empresa. O ambiente ágil há muito interação entre equipe e cliente, isto vai incomodar num ambiente silencioso.
O recomendável é uma mudança de layout com quadros nas paredes que são necessários nos métodos ágeis para controle das tarefas, outra sugestão são divisórias para cada equipe. Assim uma equipe não atrapalha outra e todos ficam bem à vontade para interação com cliente e equipe. Proporcionando a união do equipe.

Também cito que já vim ambientes aplicando métodos ágeis sem divisórias entre equipes diferentes e funcionou normalmente. Claro que tinha quadro do controle das tarefas e Daily Meeting.

As mudanças provém com aprovação do presidente e diretores da empresa é claro.

Convencendo e estimulando todo ambiente à cultura ágil entra naturalmente e a motivação das equipes na execução de tarefas renderá frutos melhores.

Software de boa qualidade que satisfaça a necessidade do cliente com agilidade e colhendo bons frutos para empresa.

Bye see you next post

terça-feira, 20 de outubro de 2009

Scrum e Psicologia

brain-speaks-paralysis

Analisando a interação da equipe em torno do sprint, fatores psicológicos são importantes de serem analisados. Os profissionais deverão ser abertos as opiniões, criticas construtivas e darem suas sugestões.

Nas reuniões diárias os profissionais não devem omitir nada no relato do que fizeram ontem, o que vão fazer hoje e obstáculos. Senão sprint não anda.

Na verdade equipe deve vestir o scrum. Com foco no termino do sprint com qualidade. Deve haver motivação, entusiasmo, coragem, autogerenciamento, autoconfiança e auto-estima. Um profissional da psicologia ou ligado neurolingüística ajudará bastante o scrum master e equipe nas características citadas e outros fatores comportamentais.

Outro momento é do spring retrospectiva, onde Scrum Master junto à equipe revê o que funcionou bem e pode melhorar para próximo sprint. A equipe deverá ser aberta as sugestões de melhora. E pensar que errar é humano e consertar é um gesto humano e profissional.

Se equipe for composta por profissionais que sejam uma fogueira de vaidade, provavelmente não aceitaram críticas construtivas. Estes profissionais não serão adequado a cultura ágil com tanta interatividade entre a equipe.

"Determinação coragem e autoconfiança são fatores decisivos para o sucesso.
Se estamos possuídos por uma inabalável determinação conseguiremos supera-lós.
Independentemente das circunstâncias,devemos ser sempre humildes,recatados e despidos de orgulho." Dalai Lama

Vocabulário

Neurolingüística: é a ciência que estuda a elaboração cerebral da linguagem. Ocupa-se com o estudo dos mecanismos do cérebro humano que suportam a compreensão, produção e conhecimento abstrato da língua, seja ela falada, escrita, ou assinalada. Trata tanto da elaboração da linguagem normal, como dos distúrbios clínicos que geram suas alterações.


Bye see you next post

segunda-feira, 19 de outubro de 2009

Coach XP

O coach é profissional experiente em metodologia e nem tanto em tecnologia. Também é Habilitado há treinar a equipe na metodologia.


Geralmente o coach é contratado de outra empresa. Seu papel diminui com amadurecimento da equipe. Os trabalhos do coach num projeto XP são:
  1. Identificar as melhores habilidades de cada recurso da equipe;
  2. Sempre lembrar as regras do XP, quando esta caindo no esquecimento;
  3. Não desenha arquitetura do sistema, apenas identifica as possíveis melhorias;
  4. Pode participar da programação pareada.
Bye see you next post.

domingo, 18 de outubro de 2009

Scrum ou XP?

A escolha do Scrum e XP depende do cliente e a prestadora de serviço.
 
O XP novo comporta equipes maiores, assim pode ser voltado para projetos maiores.

Muitas equipes e prestadoras de serviços aplicam XP e Scrum. Porque que o Scrum é voltado para gestão de projetos e XP para engenharia do software(design, integração contínua, propriedade coletiva do código, refatoração, etc.). Mas digo que tem várias equipes e prestadores de serviços que aplicam somente Scrum ou somente XP.

A escolha deve ser baseada em fatores como a aceitação do cliente da cultura dos métodos ágeis e a experiência da prestadora de serviço em lidar com metodologias ágeis com cliente.

Outra alternativa é usar o Lean(fluxo contínuo) que pode ser usado sozinho, mas este é assunto para outro artigo. Se fosse visto como conjunto o Lean possui todas as práticas Agile.

Como Scrum é para gestão de projeto é necessário a parte de engenharia de software que temos no XP, neste caso aconselho adoção de Scrum e XP.

Bye see you next post.


sábado, 17 de outubro de 2009

Scrum Aplicado no Mercado Bancário e Financeiro

Vi um vídeo interessante do Blog Visão Ágil sobre Scrum aplicado no mercado bancário e financeiro.

Como trabalhei para bancos, posso afirmar que grande parte dos sistemas bancários e financeiros são de plataforma alta e menor parte de plataforma baixa.

Plataforma Alta - Mainframe

Geralmente a migração de um sistema bancário e financeiro é lenta, envolvendo negócios críticos. Sistemas que rodam há anos e consolidados. Isto acontece no mercado brasileiro e mundial.

A comunicação entre plataformas baixa e alta é uma forma de migração. Os negócios ficam na plataforma alta e a parte visual é remodelada na plataforma baixa.

A utilização do Scrum(gestão de projeto) implica em começar a migração por sistemas menores. Na migração sem Scrum também é iniciada por sistemas menores. Metaforicamente falando: é comer o mingau pelas beiradas.

O vídeo retrata a construção de um sistema menor e aplicação do Scrum: Entrevista sobre experiências com Scrum num ambiente Bancário/Financeiro

O legal deste vídeo é que mostra até a dificuldade de entregar um Sprint com todas tarefas concluídas e como conseguir resolver esta dificuldade. A solução aplicada foi entregar cada item concluído pelo team para PO antes de fechar a Sprint, usando Scrum juntamente com Lean e FDD.

Fonte: http://visaoagil.wordpress.com/

Vocabulário

Plataforma alta ou sistemas legados: são sistemas que rodam em mainframe, geralmente em cobol usando o mainframe da IBM ou Unisys.

Plataforma baixa: são sistemas intranet, client-server e internet.

Bye see you post next.

sexta-feira, 16 de outubro de 2009

ThoughtWorks: pé no Tecnopuc

ThoughtWorks: pé no Tecnopuc

Fonte:http://www.baguete.com.br/

Quadro do Scrum

Quadro do Scrum criado pela Bluesoft feito a tinta bem prático de ser implementado:

Bye see you next post

O que é Scrum?


É um método ágil. Usado para controlar e gerenciar desenvolvimentos de softwares e produtos de forma interativa e incremental.

Os pais do Scrum são:

Jeff Shutterland, Ken Shawaber e Mike Beeble.

O Framework Scrum é formado por três partes, que são elas:

  • Papéis do Scrum(Roles);
  • Artefatos Scrum(Artifacts);
  • Cerimônias Scrum(Cerimonies).
1.Ciclo do Sprint


Lembrando que Sprint leva entre 2 a 4 semanas. E todos dias tem reunião 15 a 20 minutos.
A equipe deve ser comprometida e motivada no desenvolvimento do produto, pessoas não comprometidas numa equipe Scrum não duram e podem causar o fracasso no desenvolvimento do produto.
A equipe deve ser integrada, mesmo a distância.

2.Papéis do Scrum

1)Product Owner

O Product Owner pode ser representado tanto pelo cliente como pelo analista de negócios.

As atribuições do Product Owner são:

  • Representa todos interessados no resultado do produto;
  • Aprova o reprova os resultados das tarefas do Sprint;
  • Definição de características e conteúdos do produto;
  • Priorização de tarefas conforme entrega;
  • Define data de término.
2) Equipe

As atribuições da equipe(5 a 9 pessoas no máximo) são:
  • Desenvolvedores;
  • Auto-Gerenciáveis;
  • Multifuncional.

3) Scrum Master

É um líder da equipe que deve trabalhar para que equipe mantenha o foco do Sprint.

A atribuição do Scrum Master:

  • Remover obstáculos que possam atingir o foco da equipe no Sprint que esta sendo trabalhado.

Obs.: É necessário manter o foco da equipe no Sprint,  porque se uma tarefa não terminar no tempo do Sprint, passa para outro Sprint. O Sprint não estica o tempo por causa de uma tarefa, porisso passa para outro Sprint conforme prioridade.

3. Artefatos

1)Product Backlog

É lista de funcionalidades definida pelo Product Owner e Cliente conforme prioridade de entrega, que poderão mudar dinamicamente.

Esta funcionalidades vão formar uma lista do que fazer.

2)Sprint Backlog

É definido no Sprint Planning.

Temos os seguintes passos para formação do Sprint Backlog:

O Product Owner apresenta as funcionalidades de maior prioridade. Então equipe seleciona as funcionalidades para compor o Sprint e quebra em tarefas. O Product Owner e equipe definem o Sprint Goal e é criado Sprint Backlog.

4.Cerimoniais

1)Daily Scrum Meeting(reuniões diárias com participação do Scrum Master) 

A equipe terá todos os dias reuniões de 15 a 20 minutos com hora certa para começar. É aconselhável fazer a reunião pela manhã. As seguintes questões serão reportadas por cada pessoa da equipe:

O que fez desde última reunião?

O que fará entre essa e a próxima reunião?

Há obstáculo para realizar a tarefa?

Dúvidas devem ser reportadas no decorrer do dia, não se deve deixar dúvida para reunião.

Após a reunião a equipe vai trabalhar os obstáculos.

Duas ferramentas que são necessárias no controle do Sprint:

a) O Kanban é forma de acompanhamento das tarefas do Sprint:

 

 

 

 

 

 

 

 

O Kanban mostra o fluxo das tarefas, aqui coloquei um exemplo simples com três colunas:

Não Foi Iniciada, Iniciada e Pronta.

Usei uma tabelinha do Word. Mas geralmente o mais comum é usar um quadro com posts coloridos e com mais informações. Por exemplo dados sobre: analise, desenvolvimento e teste.

Também existem softwares para Kanban.

b) O BurnDown é uma espécie de gráfico de amortização de horas de realização de um Sprint do inicio até fim(entrega):

 
 
As reuniões diárias com as ferramentas citadas diminuem  o atraso da entrega de um projeto, pois há mecanismo de entrega por Sprint com qualidade e controle diário. Sendo processo realizado de forma incremental. 

2)Sprint Review
 
No Sprint Review são apresentados os resultados do Sprint, após fechamento do ciclo de 2 a 4 semanas.
 
Apresentação é feita através do demo das novas funcionalidades.
 
Todos interessados participam da apresentação do Sprint que é informal.

3)Sprint Retrospective

Neste Sprint o Scrum Master junto a equipe revê o que funcionou bem e que pode melhorar para próximo Sprint.
Aconselho uma tabela para colocar estas informações e trabalhar com a equipe.


 
Bye see you post next




quarta-feira, 14 de outubro de 2009

Entrevista com Fábio Rilston sobre a adoção de metodologias ágeis no SERPRO

Métodos Ágeis

Estive lendo sobre métodos ágeis e lembrei na época que usei XP parcialmente numa empresa pequena.

Lembrando que XP em 2003, senão usasse tudo não era considerado XP. Digamos que havia um radicalismo. Mas tudo amadurece nesta vida.

O Aprendizado da faculdade sobre analise estruturada e outros não impedem de usarmos os métodos ágeis com algumas modificações e adequações de pensamentos. E derrubam certas práticas como calculo de ponto de função, geralmente por experiência já percebi que várias vezes não satisfazem as exceptivas dos clientes.

O motivo era quase sempre porque os clientes esperavam um tempo menor para entrega do produto e os prestadores de serviços aplicando todas variáveis de cálculos chegavam a um tempo maior para entrega o produto.

Na minha opinião nem clientes e prestadores de serviços são os culpados pelo ponto de função não funcionar e sim a forma de elaboração do cálculos tem algumas falhas. Porque nem tudo na informática é exato, temos vários fatores não exatos: como riscos e prever o futuro.

Para diminuir os riscos na entrega do produto em gerência de software é colocado um tempo maior(sobretaxa) na entrega do produto, uma das cinco doenças de gerência de software. Mas isto é outro assunto.

Métodos ágeis é um dia de cada vez e desenvolvimento de software é feito através interações curtas, temos verificações todos os dias das funcionalidades e desenvolvimento baseado em teste(o código do cliente).

Em métodos ágeis o produto de software é desenvolvido de forma incremental.

Os princípios básicos da metodologia ágil são:

  1. Interação da equipe;
  2. Software funcionando é mais importante que documentação, mas isto não elimina um bom projeto para desenvolvimento de um software;
  3. Cliente colaborando;
  4. Mudanças são bem vindas. Software totalmente dinâmico.

Vários encontros de métodos ágeis ocorrem no país e fora. O próximo tema será scrum.

Fontes: http://visaoagil.wordpress.com/
http://www.agilcoop.org.br/
Bye see you next post.