[Rio-pm] Pair Programming

[Nuba Princigalli]

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

-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://mail.pm.org/pipermail/rio-pm/attachments/20120314/b12a1715/attachment.html>