Deposite seu voto hoje! Verifique a nova pesquisa de opinião do grupo visaoagil:

Quais processos ágeis você já usou em seus projetos?
(Escolha todas que se aplicam)


o ASD
o DSDM
o FDD
o Scrum
o XP
o Outras

Para votar, visite a seguinte web page:

http://br.groups.yahoo.com/group/visaoagil/polls

Nota: Não responda a esta mensagem. Votos de pesquisas não são coletados por e-mail. Para votar, é preciso ir ao site do Yahoo! Grupos listado acima.

Obrigado!

Temos um pessoal de negócios e um pessoal técnicos ?

Estava muito tendencioso a implantar o RUP mas de uma forma light.
Pois senti um pouco de carência nos métodos ágeis em relação a
documentação de negócio.

Se puderem ajudar com mais informações, agradeço.

Temos um pessoal de negócios e um pessoal técnicos ?

Estava muito tendencioso a implantar o RUP mas de uma forma light.
Pois senti um pouco de carência nos métodos ágeis em relação a
documentação de negócio.

Se puderem ajudar com mais informações, agradeço.

se vocês utilizarem RUP de verdade, é uma boa metodologia ...
mas não esqueça que 90% das empresas, pelo menos no brasil que dizem usar RUP, usam é Waterfall ...
RUP é interativo, da mesma forma que Scrum é interativo ...

mas eu ainda sugiro Scrum em vez de RUP.
mais uma coisa, documentação desatualizada é pior do que não existir documentação ...

On 7/27/07, mauroerd <mdurante@... > wrote:

Temos um pessoal de negócios e um pessoal técnicos ?

Estava muito tendencioso a implantar o RUP mas de uma forma light.
Pois senti um pouco de carência nos métodos ágeis em relação a
documentação de negócio.

Se puderem ajudar com mais informações, agradeço.

Excelente, ponto de vista Eduardo,

Essa idéia aplica claramente o conceito de "Baby-Steps", ou seja
você começa a usar um processo aos poucos e de maneira
evolucionária, dessa forma, você realmente evita a inércia de
análise por um processo, já começa a testa-lo em seu ambiente e
ganha um visão prática para poder adapta-lo a sua realidade com base
na exploração diária do mesmo.

Grato,

______________________________
Manoel Pimentel
Dir. Editorial - Revista Visão Ágil
www.visaoagil.com

--- Em visaoagil@..., "Eduardo Miranda" <dudamir@...>
escreveu
>
> Mauro,
>
> O Scrum é muito mais leve que o RUP, e também mais voltado para a
gerência
> do que propriamente para a execução (leia-se documentos, práticas
de
> codificação, etapas, etc)
>
> Sugiro que invés de começar do RUP e tentar agilizá-lo eu
partitiria do
> SCRUM e tentaria adaptá-lo para as minhas necessidades. É uma
questão de
> ponto de vista inicial Sair do simples para o mais complexo, vai
te levar a
> perguntar "realmente preciso disto?" para cada artefato ou métrica
nova.
>
> Eduardo Miranda
> www.eduardomiranda.net/blogs/dotnet/
>
>
> Em 27/07/07, Rodrigo Jardim <rodrigo@...> escreveu:
> >
> > se vocês utilizarem RUP de verdade, é uma boa metodologia ...
> > mas não esqueça que 90% das empresas, pelo menos no brasil que
dizem usar
> > RUP, usam é Waterfall ...
> > RUP é interativo, da mesma forma que Scrum é interativo ...
> >
> > mas eu ainda sugiro Scrum em vez de RUP.
> > mais uma coisa, documentação desatualizada é pior do que não
existir
> > documentação ...
> >
> > On 7/27/07, mauroerd <mdurante@...> wrote:
> > >
> > > Temos um pessoal de negócios e um pessoal técnicos ?
> > >
> > > Estava muito tendencioso a implantar o RUP mas de uma forma
light.
> > > Pois senti um pouco de carência nos métodos ágeis em relação a
> > > documentação de negócio.
> > >
> > > Se puderem ajudar com mais informações, agradeço.
> > >
> > >
> >
> >
>

Pessoal, andei lendo sobre local de trabalho informativo mas ainda tenho
algumas duvidas.. por exemplo.. havera tres seções: Em Andamento, Nao
Iniciadas e Finalizadas.

Mas em cada uma destas seção elas conteram o que? Por exemplo de um
sistema baseado em telas( Cadastro de Pessoa, Cadastro de Usuario e etc
) eu coloco cartoes com as telas a serem desenvolvidas? Ou
funcionalidades que o cliente exige(por exemplo, que o sistema gere
boletos e relatorios)?

Pessoal, andei lendo sobre local de trabalho informativo mas ainda tenho
algumas duvidas.. por exemplo.. havera tres seções: Em Andamento, Nao
Iniciadas e Finalizadas.

Mas em cada uma destas seção elas conteram o que? Por exemplo de um
sistema baseado em telas( Cadastro de Pessoa, Cadastro de Usuario e etc
) eu coloco cartoes com as telas a serem desenvolvidas? Ou
funcionalidades que o cliente exige(por exemplo, que o sistema gere
boletos e relatorios)?

Olá Bruno,

Só a título de sugestão:

Fazendo um "mix" com FDD, estamos trabalhando com quatro áreas, que
seriam:

- Não Iniciadas
- Iniciadas
- Inspeção
- Concluídas

Onde os itens assim que passam pelos testes unitários, são disponíveis
para inspeção de código, e nessa prática, obtemos os seguintes
benefícios:
- Mais um tipo de teste;
- Conseguimos certificar de que os padrões de código e de design
estão sendo seguidos;
- Sugerir refatorações;
- Compartilhamos conhecimento acerca do código, pois não existe a
figura de um único "inspetor", na verdade, a inspeção pode ser feita em
forma de rodízio entre os membros do time, portanto, essa prática,
seria uma espécie de "pair programming" com um objetivo mais específico.

Bem como você viu, como a atividade de inspeção é uma atividade
estratégica para a qualidade do produto, fazemos questão de deixá-la
bem evidenciada nosso quadro informativo.

Grato,

Manoel Pimentel

--- Em visaoagil@..., Bruno Viana <brunoviana@...>
escreveu
>
> Pessoal, andei lendo sobre local de trabalho informativo mas ainda
tenho
> algumas duvidas.. por exemplo.. havera tres seções: Em Andamento, Nao
> Iniciadas e Finalizadas.
>
> Mas em cada uma destas seção elas conteram o que? Por exemplo de um
> sistema baseado em telas( Cadastro de Pessoa, Cadastro de Usuario e
etc
> ) eu coloco cartoes com as telas a serem desenvolvidas? Ou
> funcionalidades que o cliente exige(por exemplo, que o sistema gere
> boletos e relatorios)?
>

Olá Bruno,

Só a título de sugestão:

Fazendo um "mix" com FDD, estamos trabalhando com quatro áreas, que
seriam:

- Não Iniciadas
- Iniciadas
- Inspeção
- Concluídas

Onde os itens assim que passam pelos testes unitários, são disponíveis
para inspeção de código, e nessa prática, obtemos os seguintes
benefícios:
- Mais um tipo de teste;
- Conseguimos certificar de que os padrões de código e de design
estão sendo seguidos;
- Sugerir refatorações;
- Compartilhamos conhecimento acerca do código, pois não existe a
figura de um único "inspetor", na verdade, a inspeção pode ser feita em
forma de rodízio entre os membros do time, portanto, essa prática,
seria uma espécie de "pair programming" com um objetivo mais específico.

Bem como você viu, como a atividade de inspeção é uma atividade
estratégica para a qualidade do produto, fazemos questão de deixá-la
bem evidenciada nosso quadro informativo.

Grato,

Manoel Pimentel

--- Em visaoagil@..., Bruno Viana <brunoviana@...>
escreveu
>
> Pessoal, andei lendo sobre local de trabalho informativo mas ainda
tenho
> algumas duvidas.. por exemplo.. havera tres seções: Em Andamento, Nao
> Iniciadas e Finalizadas.
>
> Mas em cada uma destas seção elas conteram o que? Por exemplo de um
> sistema baseado em telas( Cadastro de Pessoa, Cadastro de Usuario e
etc
> ) eu coloco cartoes com as telas a serem desenvolvidas? Ou
> funcionalidades que o cliente exige(por exemplo, que o sistema gere
> boletos e relatorios)?
>

Boa noite Galera:

Esse é meu primeiro post. Achei a idéia muito interessante e espero que a revista cresça a cada dia mais!!!

EU queria saber de vocês uma coisa: que ferramenta vocês me sugeriram para gerenciamento de projetos em pequenos grupos de trabalho??? Estamos pensando em adotar Scrum na nossa empresa e queríamos uma ferramenta que nos auxiliasse, sendo que nós ainda temos o agravante de que nem todas as pessoas da equipe trabalham nos mesmos horários em tempo integral e/ou trabalham via net.

E aproveitando: Considerando o escrito acima: será que Scrum seria uma boa? ou existem metodologias mais interessantes para esse caso?

Obrigado

 

Igor Silvério Costa

MasterSoft - Soluções Corporativas

Alertas do Yahoo! Mail em seu celular. Saiba mais.

Manoel,

Você utiliza o pair programming nesse caso onde há um momento onde as tarefas são inspecionadas?
No caso dos que usam o pair programming não torna-se desnecessário esta inspeção?

Um abraço

Ricardo

Em 03/08/07, Manoel Pimentel < manoel_consultor@...> escreveu:

Olá Bruno,

Só a título de sugestão:

Fazendo um "mix" com FDD, estamos trabalhando com quatro áreas, que
seriam:

- Não Iniciadas
- Iniciadas
- Inspeção
- Concluídas

Onde os itens assim que passam pelos testes unitários, são disponíveis
para inspeção de código, e nessa prática, obtemos os seguintes
benefícios:
- Mais um tipo de teste;
- Conseguimos certificar de que os padrões de código e de design
estão sendo seguidos;
- Sugerir refatorações;
- Compartilhamos conhecimento acerca do código, pois não existe a
figura de um único "inspetor", na verdade, a inspeção pode ser feita em
forma de rodízio entre os membros do time, portanto, essa prática,
seria uma espécie de "pair programming" com um objetivo mais específico.

Bem como você viu, como a atividade de inspeção é uma atividade
estratégica para a qualidade do produto, fazemos questão de deixá-la
bem evidenciada nosso quadro informativo.

Grato,

Manoel Pimentel

--- Em visaoagil@..., Bruno Viana <brunoviana@...>
escreveu
>
> Pessoal, andei lendo sobre local de trabalho informativo mas ainda
tenho
> algumas duvidas.. por exemplo.. havera tres seções: Em Andamento, Nao
> Iniciadas e Finalizadas.
>
> Mas em cada uma destas seção elas conteram o que? Por exemplo de um
> sistema baseado em telas( Cadastro de Pessoa, Cadastro de Usuario e
etc
> ) eu coloco cartoes com as telas a serem desenvolvidas? Ou
> funcionalidades que o cliente exige(por exemplo, que o sistema gere
> boletos e relatorios)?
>

--
Ricardo Mitrano

--- Em visaoagil@..., Igor Silvério Costa
<igor_uesb@...> escreveu
>
> Boa noite Galera:

Boa

> Esse é meu primeiro post. Achei a idéia muito interessante e espero
que a revista cresça a cada dia mais!!!

Primeiro post também, concordo, a idéia e o conteúdo da revista esta
muito bom, parabéns.

> EU queria saber de vocês uma coisa: que ferramenta vocês me
sugeriram para gerenciamento de projetos em pequenos grupos de
trabalho??? Estamos pensando em adotar Scrum na nossa empresa e
queríamos uma ferramenta que nos auxiliasse, sendo que nós ainda temos
o agravante de que nem todas as pessoas da equipe trabalham nos mesmos
horários em tempo integral e/ou trabalham via net.

Conheci há alguns dias uma ferramenta chamada mingle, da ThoughtWorks
(que acredito ser velha conhecida de todos aqui).

É uma ferramenta excelente!!! Possui templates para gerenciamento de
projetos (você não deve se sentir "perdido" com ela), é fácil de usar
(você não perde mais tempo anotando algo do que fazendo esse algo), é
via web (ou seja, tem acesso de onde estiver) e para até 5 usuários,
não tem custo (há algumas observações).

Bastante simples de usar e assistindo aos screencasts da ferramenta, é
instalar e usar.

Mesmo para quem já utiliza alguma ferramenta, vale a pena da uma
olhada, nem que seja apenas por curiosidade:

http://studios.thoughtworks.com/mingle-project-intelligence
http://studios.thoughtworks.com/mingle-project-intelligence/videos

> E aproveitando: Considerando o escrito acima: será que Scrum seria
uma boa? ou existem metodologias mais interessantes para esse caso?
>
> Obrigado
>
> Igor Silvério Costa
> MasterSoft - Soluções Corporativas

É isso,
Eziel Silva

muito boa a ferramenta! mas que tal fazer, de inicício, uso de uma parede branca, alguns post-its e muita conversa??

será mesmo necessária a utilização de uma ferramenta para um grupo pequeno? já usei em um projetos apenas um arquivo de textos(simulando a parede) para que os clientes pudessem ter acesso aos itens da iteração via internet... extremamente simples:

* Iteração atual

* Proximos itens (por prioridade)

* "Gordurinha" (itens que são bastante simples que podem ser feitos caso os itens da iteração tenham terminado e ainda falte tempo)

* Histório das iterações (o registro do que foi entregue na semana anteriores)


Pode ser um incício... que tal?

On 8/4/07, ano_nimousx <ano_nimousx@...> wrote:

--- Em visaoagil@..., Igor Silvério Costa
<igor_uesb@...> escreveu
>
> Boa noite Galera:

Boa

> Esse é meu primeiro post. Achei a idéia muito interessante e espero
que a revista cresça a cada dia mais!!!

Primeiro post também, concordo, a idéia e o conteúdo da revista esta
muito bom, parabéns.

> EU queria saber de vocês uma coisa: que ferramenta vocês me
sugeriram para gerenciamento de projetos em pequenos grupos de
trabalho??? Estamos pensando em adotar Scrum na nossa empresa e
queríamos uma ferramenta que nos auxiliasse, sendo que nós ainda temos
o agravante de que nem todas as pessoas da equipe trabalham nos mesmos
horários em tempo integral e/ou trabalham via net.

Conheci há alguns dias uma ferramenta chamada mingle, da ThoughtWorks
(que acredito ser velha conhecida de todos aqui).

É uma ferramenta excelente!!! Possui templates para gerenciamento de
projetos (você não deve se sentir "perdido" com ela), é fácil de usar
(você não perde mais tempo anotando algo do que fazendo esse algo), é
via web (ou seja, tem acesso de onde estiver) e para até 5 usuários,
não tem custo (há algumas observações).

Bastante simples de usar e assistindo aos screencasts da ferramenta, é
instalar e usar.

Mesmo para quem já utiliza alguma ferramenta, vale a pena da uma
olhada, nem que seja apenas por curiosidade:

http://studios.thoughtworks.com/mingle-project-intelligence
http://studios.thoughtworks.com/mingle-project-intelligence/videos

> E aproveitando: Considerando o escrito acima: será que Scrum seria
uma boa? ou existem metodologias mais interessantes para esse caso?
>
> Obrigado
>
> Igor Silvério Costa
> MasterSoft - Soluções Corporativas

É isso,
Eziel Silva

--
Por um mundo sem debug - dojoFloripa

Victor Hugo Germano
Fone: (48) 8801-7535
Email: victorhg@...

Vc não poderia trocar a 'parede' por um wiki ?

On 8/5/07, Victor Hugo Germano <victorhg@...> wrote:

muito boa a ferramenta! mas que tal fazer, de inicício, uso de uma parede branca, alguns post-its e muita conversa??

será mesmo necessária a utilização de uma ferramenta para um grupo pequeno? já usei em um projetos apenas um arquivo de textos(simulando a parede) para que os clientes pudessem ter acesso aos itens da iteração via internet... extremamente simples:

* Iteração atual

* Proximos itens (por prioridade)

* "Gordurinha" (itens que são bastante simples que podem ser feitos caso os itens da iteração tenham terminado e ainda falte tempo)

* Histório das iterações (o registro do que foi entregue na semana anteriores)


Pode ser um incício... que tal?

On 8/4/07, ano_nimousx <ano_nimousx@...> wrote:

--- Em visaoagil@..., Igor Silvério Costa
<igor_uesb@...> escreveu
>
> Boa noite Galera:

Boa

> Esse é meu primeiro post. Achei a idéia muito interessante e espero
que a revista cresça a cada dia mais!!!

Primeiro post também, concordo, a idéia e o conteúdo da revista esta
muito bom, parabéns.

> EU queria saber de vocês uma coisa: que ferramenta vocês me
sugeriram para gerenciamento de projetos em pequenos grupos de
trabalho??? Estamos pensando em adotar Scrum na nossa empresa e
queríamos uma ferramenta que nos auxiliasse, sendo que nós ainda temos
o agravante de que nem todas as pessoas da equipe trabalham nos mesmos
horários em tempo integral e/ou trabalham via net.

Conheci há alguns dias uma ferramenta chamada mingle, da ThoughtWorks
(que acredito ser velha conhecida de todos aqui).

É uma ferramenta excelente!!! Possui templates para gerenciamento de
projetos (você não deve se sentir "perdido" com ela), é fácil de usar
(você não perde mais tempo anotando algo do que fazendo esse algo), é
via web (ou seja, tem acesso de onde estiver) e para até 5 usuários,
não tem custo (há algumas observações).

Bastante simples de usar e assistindo aos screencasts da ferramenta, é
instalar e usar.

Mesmo para quem já utiliza alguma ferramenta, vale a pena da uma
olhada, nem que seja apenas por curiosidade:

http://studios.thoughtworks.com/mingle-project-intelligence
http://studios.thoughtworks.com/mingle-project-intelligence/videos

> E aproveitando: Considerando o escrito acima: será que Scrum seria
uma boa? ou existem metodologias mais interessantes para esse caso?
>
> Obrigado
>
> Igor Silvério Costa
> MasterSoft - Soluções Corporativas

É isso,
Eziel Silva

--
Por um mundo sem debug - dojoFloripa

Victor Hugo Germano
Fone: (48) 8801-7535
Email: victorhg@...

--
Tiago B Peczenyj
Linux User #405772

http://peczenyj.blogspot.com/

Vc não poderia trocar a 'parede' por um wiki ?

On 8/5/07, Victor Hugo Germano <victorhg@...> wrote:

muito boa a ferramenta! mas que tal fazer, de inicício, uso de uma parede branca, alguns post-its e muita conversa??

será mesmo necessária a utilização de uma ferramenta para um grupo pequeno? já usei em um projetos apenas um arquivo de textos(simulando a parede) para que os clientes pudessem ter acesso aos itens da iteração via internet... extremamente simples:

* Iteração atual

* Proximos itens (por prioridade)

* "Gordurinha" (itens que são bastante simples que podem ser feitos caso os itens da iteração tenham terminado e ainda falte tempo)

* Histório das iterações (o registro do que foi entregue na semana anteriores)


Pode ser um incício... que tal?

On 8/4/07, ano_nimousx <ano_nimousx@...> wrote:

--- Em visaoagil@..., Igor Silvério Costa
<igor_uesb@...> escreveu
>
> Boa noite Galera:

Boa

> Esse é meu primeiro post. Achei a idéia muito interessante e espero
que a revista cresça a cada dia mais!!!

Primeiro post também, concordo, a idéia e o conteúdo da revista esta
muito bom, parabéns.

> EU queria saber de vocês uma coisa: que ferramenta vocês me
sugeriram para gerenciamento de projetos em pequenos grupos de
trabalho??? Estamos pensando em adotar Scrum na nossa empresa e
queríamos uma ferramenta que nos auxiliasse, sendo que nós ainda temos
o agravante de que nem todas as pessoas da equipe trabalham nos mesmos
horários em tempo integral e/ou trabalham via net.

Conheci há alguns dias uma ferramenta chamada mingle, da ThoughtWorks
(que acredito ser velha conhecida de todos aqui).

É uma ferramenta excelente!!! Possui templates para gerenciamento de
projetos (você não deve se sentir "perdido" com ela), é fácil de usar
(você não perde mais tempo anotando algo do que fazendo esse algo), é
via web (ou seja, tem acesso de onde estiver) e para até 5 usuários,
não tem custo (há algumas observações).

Bastante simples de usar e assistindo aos screencasts da ferramenta, é
instalar e usar.

Mesmo para quem já utiliza alguma ferramenta, vale a pena da uma
olhada, nem que seja apenas por curiosidade:

http://studios.thoughtworks.com/mingle-project-intelligence
http://studios.thoughtworks.com/mingle-project-intelligence/videos

> E aproveitando: Considerando o escrito acima: será que Scrum seria
uma boa? ou existem metodologias mais interessantes para esse caso?
>
> Obrigado
>
> Igor Silvério Costa
> MasterSoft - Soluções Corporativas

É isso,
Eziel Silva

--
Por um mundo sem debug - dojoFloripa

Victor Hugo Germano
Fone: (48) 8801-7535
Email: victorhg@...

--
Tiago B Peczenyj
Linux User #405772

http://peczenyj.blogspot.com/

The most important reason to inspect documents is to prevent defects. If the team starts building software based on a vision and scope document that has a serious defect, eventually the entire project will have to stop and reverse course. This can be very expensive in both effort and morale, because the team will need to backtrack and revise the requirements, design, code, test plans, and other work products that they have already put a lot of effort into implementing. The same goes for defects that were caught in other work productsdefects missed in a design specification, for example, will have to be corrected later after they have been coded. The longer a defect goes uncorrected, the more entrenched it is in other work products; the more entrenched it is, the more time and effort it will take to fix.

According to a report by the Software Engineering Institute, it costs more to not do inspections than it does to do them. A national survey of software engineering teams found that in a typical inspection, four to five people spend one to two hours preparing for inspections, followed by one to two hours to hold an inspection meeting. The total effort required for the inspection, therefore, is 10 to 20 person-hours; this effort results in the early detection of an average of 5 to 10 defects. (On the average, these defects, if left in the document, would require either 250 to 500 lines of new code or modification of 1000 to 1500 lines of legacy code to repair if they were eventually caughtwhich would almost certainly require well over 20 person-hours of programmers' time!) This is a very high return on investment; few tools, techniques, or practices are as effective as inspections for increasing the quality of the software.

Inspections are easy to implement, and have an immediate effect on quality and consensus-building. A small team spending a few hours inspecting a work product will catch errors that could potentially save weeks, or even months, of wasted effort. An effective inspection requires a well-chosen team, a moderator who is able to run the meeting, and an author who is willing to listen to criticism and fix the work product being inspected.

Pair programming é um forma de inspeção Ricardo. Assim, durante o desenvolvimento existe a interação entre os programadores, e o que chamamos de "pressao da dupla", fazendo com que um programador não faça coisas mal feitas(ou melhor "gambiarras") pois tem alguém do lado dele que com certeza vai acabar pegando esse tipo de coisa...

lá em 2004 fiz um trabalho na faculdade sobre PP... espero que ajude:

http://xp.edugraf.ufsc.br/bin/view/XP/PairProgramming

 

.

Existem vários "mitos" sobre a XP e, na minha opinião, muitos são sobre a Programação em Pares...

 

Essa esperança de que "alguém do lado vai pegar as suas gambiarras", por exemplo, é uma "lenda urbana". Programei muito, sozinho, em par, em trio e em n-upla (principalmente na faculdade, onde apenas um ou dois fazem o trabalho num grupo de 6).

 

Sabe o que acontece mesmo? Um fica mais aprendendo ao olhar o outro programando do que realmente tentando ser um "inspetor". Por quê? Porque o programador mais experiente também é, geralmente, o menos paciente, pois se ele sabe fazer, não aguenta ficar ensinando e esperando o outro errar para corrigir... Ele senta no teclado e faz... E nem sempre o outro (menos experiente) conseguirá ter argumentos suficientes para mostrar que a "gambiarra" que porventura esteja sendo feita é, de fato, uma "gambiarra" (vamos ser honestos: quantas "gambiarras" suas já salvaram o dia?).

 

Assim, tentar fazer equivalência entre uma prática formal e amplamente estudada como a inspeção com algo puramente empírico e subjetivo, como a PP, é algo que não consigo deixar passar sem deixar um enorme aviso de CUIDADO!

 

Sugiro estudar melhor o assunto da inspeção antes de continuar a passar essa "lenda urbana" prá frente. Um bom ponto de partida é

o trabalho do Prof. Guilherme Horta (http://www.cos.ufrj.br/~ght), da COPPE/UFRJ, que lidera uma equipe que tem demonstrado o real benefício das inspeções, contrastando com outras técnicas de revisão. Procure pelos seus artigos e apresentações.

Se puder ler em inglês, esse artigo no blog Chip Overclock e seus comentários é, no mínimo, interessante:
http://coverclock.blogspot.com/2007/01/pair-programming-is-bad-and-you-should.html

Ainda se puder ler em inglês, segue um trecho do livro "Applied Software Project Management", sobre inspeção:

The most important reason to inspect documents is to prevent defects. If the team starts building software based on a vision and scope document that has a serious defect, eventually the entire project will have to stop and reverse course. This can be very expensive in both effort and morale, because the team will need to backtrack and revise the requirements, design, code, test plans, and other work products that they have already put a lot of effort into implementing. The same goes for defects that were caught in other work productsdefects missed in a design specification, for example, will have to be corrected later after they have been coded. The longer a defect goes uncorrected, the more entrenched it is in other work products; the more entrenched it is, the more time and effort it will take to fix.

According to a report by the Software Engineering Institute, it costs more to not do inspections than it does to do them. A national survey of software engineering teams found that in a typical inspection, four to five people spend one to two hours preparing for inspections, followed by one to two hours to hold an inspection meeting. The total effort required for the inspection, therefore, is 10 to 20 person-hours; this effort results in the early detection of an average of 5 to 10 defects. (On the average, these defects, if left in the document, would require either 250 to 500 lines of new code or modification of 1000 to 1500 lines of legacy code to repair if they were eventually caughtwhich would almost certainly require well over 20 person-hours of programmers' time!) This is a very high return on investment; few tools, techniques, or practices are as effective as inspections for increasing the quality of the software.

Inspections are easy to implement, and have an immediate effect on quality and consensus-building. A small team spending a few hours inspecting a work product will catch errors that could potentially save weeks, or even months, of wasted effort. An effective inspection requires a well-chosen team, a moderator who is able to run the meeting, and an author who is willing to listen to criticism and fix the work product being inspected.

 

Enfim, além de não ser tecnicamente muito efetiva, a Programação em Pares também enfrenta o desafio de ser justificável economicamente (tente convencer seu chefe que não são 2 fazendo o trabalho de 1...). A tendência é muito mais para a Programação Colaborativa do que a PP.

 

Quanto aos benefícios, a inspeção não somente atinge os mesmos objetivos que a PP (distribuição do conhecimento), como faz isso de forma muito mais ampla e formal (isto é, com registros, o que é fundamental para qualquer iniciativa de avaliação - CMMI, MPS.BR, ISO, etc.). Com a PP, vai saber...

 

Heptabraço,

 

Adail

 

On 8/4/07, Victor Hugo Germano <victorhg@... > wrote:

Pair programming é um forma de inspeção Ricardo. Assim, durante o desenvolvimento existe a interação entre os programadores, e o que chamamos de "pressao da dupla", fazendo com que um programador não faça coisas mal feitas(ou melhor "gambiarras") pois tem alguém do lado dele que com certeza vai acabar pegando esse tipo de coisa...

lá em 2004 fiz um trabalho na faculdade sobre PP... espero que ajude:

http://xp.edugraf.ufsc.br/bin/view/XP/PairProgramming

 

.