[Rio-pm] Pair Programming

thiagoglauco em ticursos.net thiagoglauco em ticursos.net
Quarta Março 14 07:27:29 PDT 2012


"Que coisa boa é uma equipe pequena em um projeto pequeno! onde boa  
comunicação e profissionalismo resolvem muitos dos problemas que, nas  
equipes grandes, demandam a adoção de metodologias e processos cheios  
de overhead.

Aí alguem vai falar: mas e os sistemas grandes, quem faz? Simples:  
melhor construir vários sistemas pequenos, cada um expondo uma API  
desenhada com carinho, e terminar com uma plataforma nas mãos, ao  
invés dum sistema monolítico.

Se isso funciona?.. Pergunte à Amazon! ;)"

Concordo.

  1- Dividir para conquistar
  2- Prefiro uma boa estrategia em um esquadrao de elite 'a um grande  
exercito mau organizado.

Citando Nuba Princigalli <nuba em fastmail.fm>:

> Caros,
>
> Essa thread está muito interessante :) respondendo intercalando
> abaixo...
>
> On Tue, Mar 13, 2012, at 11:49 PM, Cleysinho wrote:
>
>   um sistema acadêmico de uma Universidade possui o seu core
>   (matriculador) em cobol até hoje
>
>   O matriculador funciona tão bem que ainda não o reescreveram.
>
>   construído no final da década de 60
>
>
> Como se diz: "If it's working, don't fix it!"
>
> Se foi bem feito em Cobol, funciona bem, e consegue acomodar as
> mudanças no domínio-problema (ou é um domínio-problema muito
> estável, "nada muda"), maravilha! O único problema é expor isso
> para sistemas novos, ou externos (parceiros, clientes). Fazer
> isso com Perl é mamão-com-açúcar: é data-munging + desenterrar
> módulos para lidar com coisas legadas, obscuras ou arcanas no
> CPAN, e também pra sua estratégia preferida para expor a API :)
>
>
> Eu particularmente gosto dos artefatos do RUP.
>
> a documentação ajudar a indetificar de forma clara as
> funcionalidades e se possível gerar uma matriz de
> rastreabilidade.
>
>
> Um jeito magro de conseguir essa rastreabilidade é adotar algumas
> coisas simples de gerência de configuração: tickets para
> mudanças, novas features, bugfixes, etc, e uma política de que
> nenhum commit é aceito no repositório sem referênciar seu
> respectivo ticket. Com isso você consegue responder, para cada
> instante do software, para cada linha, porque ela está ali.
>
>
> On Tue, Mar 13, 2012 at 8:24 PM, Marcio
> Ferreira <[1]marciodesouzaferreira em gmail.com> wrote:
> Escrever código é fácil, quero ver escrever algo que se mantenha
> intuitivo daqui 20 anos
>
>
> Dois problemas:
> * "intuitivo" parece "bom senso", aquele que cada um tem o seu :P
> * é um alvo móvel. O intuitivo de hoje não é o intuitivo de 2032
> :/
>
>
> On Tue, Mar 13, 2012 at 6:25 PM, Ricardo
> Filipo <[2]ricardo_filipo em yahoo.com.br> wrote:
> A frase seria: "Se o seu cliente pediu pra desenvolver
> determinado software,
> entregue imediatamente qualquer coisa. Na medida que o cliente
> reclamar
> vc vai fazendo o software como ele quer realmente. Aliás, o
> cliente vai
> reclamar de qualquer forma, mesmo que vc desenvolva o
> software exatamente
> como vc acha que ele queria que fosse".
>
>
> Muito verdadeiro! :) No final é a comunicação com o cliente que
> vai fazer o software que ele precisa -- não necessariamente o que
> ele quer :D -- acontecer.
>
>
> On Sun, Mar 11, 2012 at 3:33 AM, breno <[3]oainikusama em gmail.com>
> wrote:
>
> Ele chega a discutir que grupos de brainstorming costumam ter
> menos
> idéias do que o mesmo número de pessoas trabalhando sozinha e
> depois
> compartilhando idéias. A questão de escritórios sem baia
> (open-plan)
>
> também é criticada, por ser uma grande fonte de distração e
> interrupções.
>
>
> Um dos problemas das sessões de brainstorm é que aqueles com mais
> status (seja lá o que dê status no grupo) acabam dominando a
> sessão (nem sempre de propósito). Sempre há no grupo os que
> querem se alinhar com os que têm mais status, e em cima disso a
> peer pressure de se alinhar com a maioria. Uma forma de minimizar
> isso é a apresentação e discussão das idéias sem que elas estejam
> fortemente associadas aos seus proponentes, por exemplo: num
> wiki, etherpad ou googledocs.
>
>
> O que vocês acham?
>
>
> Que coisa boa é uma equipe pequena em um projeto pequeno! onde
> boa comunicação e profissionalismo resolvem muitos dos problemas
> que, nas equipes grandes, demandam a adoção de metodologias e
> processos cheios de overhead.
>
> Aí alguem vai falar: mas e os sistemas grandes, quem
> faz? Simples: melhor construir vários sistemas pequenos, cada um
> expondo uma API desenhada com carinho, e terminar com uma
> plataforma nas mãos, ao invés dum sistema monolítico.
>
> Se isso funciona?.. Pergunte à Amazon! ;)
>
> Abraço,
>
> Nuba Princigalli
>
> References
>
> 1. mailto:marciodesouzaferreira em gmail.com
> 2. mailto:ricardo_filipo em yahoo.com.br
> 3. mailto:oainikusama em gmail.com
> --
> Nuba R. Princigalli  nuba em pauleira.com  http://pauleira.com  @nprincigalli
> Discipline is not an end in itself, just a means to an end. - King Crimson
>
>




Mais detalhes sobre a lista de discussão Rio-pm