Cronograma de desenvolvimento, Drupal Brasil

[Joel Wallis]

Amigos, vamos discutir nesse tópico APENAS O CRONOGRAMA DE TRABALHOS! Vamos manter o tópico organizado.

Sugiro o seguinte (a lista organizada reflete as semanas):

1. (12/11 à 18/11) organização desse próprio cronograma;
2. (19/11 à 25/11) discussão sobre problemas da comunidade, possíveis soluções, escolhas de funcionalidades para o projeto, definições do que será feito e quando será entregue (versão 1.0, 1.1, 1.2, etc), e quem será responsável pelo que;
3. (26/11 à 02/12) organização do que já temos hoje no Github com o que será feito, preparação do servidor (instalação do que for preciso, criação das contas e acessos aos colaboradores, alinhamento com a metodologia de trabalho;
4. (03/12 à 09/12) primeira sprint;
5. (10/12 em diante) pendente.

Gostaria da opinião de vocês. Temos até o próximo domingo para discutir e aperfeiçoar isso.

--
Joel Wallis

about.me/joelwallis

[Helal Ferrari Cabral]

Eu colocaria sprint de 2 semanas para nao ficar apertado hhehehehe

--
 
 

--
Helal Ferrari Cabral
Analista de sistemas

ferrar...@gmail.com
+55 48 9122 6677
www.helalferrari.com

[Joel Wallis]

Sprints de duas semanas representam problemas maiores. A intenção é definir problemas pequenos, e se possível, revezar o trabalho.

Ex: primeira sprint: leo e tregis. Segunda: pedrão e eu. Terceira: fulano e beltrano. 

--
 
 

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

Concordo com 2 semanas... a galera vai ajudar como voluntário, não tem como comprometer muito o tempo deles (nosso)

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Pedro Rocha]

É exatamente o que falta: comprometimento. Sem responsáveis comprometidos, com metas, cobrança, datas, não vejo como algo ande.

O Drupal, projeto no qual nos baseamos para falar tudo isso aqui, se não lançar sua versão 8 ano que vem, todos estarão xingando o Dries. Quando o Views não estava pronto quando o D7 lançou, todos reclamaram.

Segue uma metáfora qu diz tudo sobre essa situação recorrente de "envolvido x comprometido"...

"A galinha e o porco montaram uma empresa de omelete. A galinha entraria com os ovos e o porco com o bacon. Nessa história fica claro que a galinha está envolvida e o porco comprometido."

Vale ler mais, inclusive: http://www.rh.com.br/Portal/Desempenho/Artigo/5841/estar-envolvido-ou-comprometido-eis-a-questao.html

abs,
Pedro Rocha

-------------

www.singleview.com.br

www.pedrorocha.net

2012/11/12 GMail | Thiago Régis <tregis...@gmail.com>

--
 
 

[Joel Wallis]

Rapaz, eu concordo com o Pedro. Se não pode comprometer-se, não comprometa-se. Cada sprint será para fazer apenas uma feature, coisa que se vc trabalhar umas 6 horas vc faz. Em um sábado com cerveja e música você faz isso.

Se por duas semanas o negócio não vai acontecer. A ideia morre, fica parada. O projeto fica "frio".

--
 
 

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

Não se pode cobrar comprometimento de todos os envolvidos quando isso não vai pagar as contas deles. Cada um tem seus compromissos com trabalho (alguns tem empresas, são empregados, são freelancers, tem seus clientes), não dá pra gente meter a faca no pescoço e falar: "você tem que concluir isso em 1 semana, porque na próxima semana tem mais coisa pra vc fazer".

É claro que estou sendo exagerado, mas a "parabola da galinha e do porco" se aplica muito bem quando você está faland. Em voluntariado é no mínimo injusto cobrar um comprometimento com um prazo tão pequeno. Uns podem topar, outros não vão poder.

Mas se der pra fazer como o Joel sugeriu (intercalar os sprints), é tranquilo. Só que há um risco das coisas fugirem do controle (cada um tem um estilo e forma de trabalho).

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Luiz Gustavo Aleagi Nunes]

+1 Thiago!

A preocupação sempre foi essa, cada pessoa tem seus compromissos e estilos de trabalho.

Talvez essa seja a dificuldade maior, unir pessoas em esforços coletivos onde todas estão podendo unir os esforços sincronizadamente.

Talvez uma saída seja a de uma pessoa que esteja com mais tempo iniciar o trabalho "grosso", edificar e então os demais que tem disponibilidade de tempo intercaladas podem ir alterando conforme seus cronogramas permitirem.

Luiz Gustavo Aleagi Nunes

Desenvolvedor Drupal | Padrões W3C | Acessibilidade

http://aleagi.com | http://eopen.com.br | http://drupal-br.org

--
 
 

[GMail | Thiago Régis]

Ou então definir tarefas bem curtinhas...

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Joel Wallis]

"Se não pode comprometer-se, não comprometa-se."

"A intenção é definir problemas pequenos, e se possível, revezar o trabalho."

"Se possível, revezar o trabalho. Ex: primeira sprint: leo e tregis. Segunda: pedrão e eu. Terceira: fulano e beltrano."

--
 
 

--
Joel Wallis

about.me/joelwallis

[Gedvan Dias]

Concordo com o sprint de 2 semanas...

Acho também que podíamos acatar a ideia do Pedro Rocha e definir bem (e documentar) os objetivos antes de colocar a mão na massa em si. Talvez os objetivos estejam claros na cabeça de cada um, mas é necessário alinhar as expectativas de todos para que fique claro onde queremos chegar.

--
 
 

[Gedvan Dias]

Na verdade, essa parte dos objetivos pode ser feita no item 2 do cronograma.

[Leonardo Silva]

Essa semana eu já me comprometi (em outro tópico) dizendo que faria um levantamento das informações e documentações já existentes.

Item 2: "discussão sobre problemas da comunidade, possíveis soluções, escolhas de funcionalidades para o projeto, definições do que será feito". Muita coisa sobre isso já foi feito e amadurecido. Fazer um review do que já tem, beleza. Mas fazer tudo de novo, não vejo sentido.

--
 
 

[Pedro Rocha]

Gente, o que o Joel falou é simples: não pode se comprometer, não se comprometa. Ninguém está obrigado a nada aqui.

Na verdade, a pessoa deveria é se sentir obrigada a cumprir com o que se comprometeu, somente isso. Logo, não se comprometa com o que não poderá cumprir.

A solução é simples: devagar e sempre. Que sejam poucos itens, mas constantes.

abs,
Pedro Rocha

-------------

www.singleview.com.br

www.pedrorocha.net

2012/11/12 Gedvan Dias <ged...@gmail.com>

--
 
 

[Bruno Rios]

pra ajudar na segunda etapa:

Funcionalidades Sugeridas discutidas anteriormente:

https://docs.google.com/document/d/1hJ7yt-1DhY3JmMWOgil0pbkdQqWKKCB2WJBscN4_Qno/edit?hl=pt_BR

--
 
 

--

Atenciosamente,

Bruno Rios

http://www.flashmedia.com.br

http://flavors.me/brunorios

[Joel Wallis]

tae, ja estamos nos alinhando. leo vai levantar esses documentos, a gente continua com a discussão do cronograma (eu pedi pra manter o foco mas é mesmo que merda hehuehuehu) e próxima semana falamos sobre problemas, soluções, funcionalidades, etc.

Voltando ao cronograma: sugestões?

[Guilherme Hayashi]

Sobre o cronograma, eu sugeria acrescentar alguns dias antes do sprint para a definição e planejamento do que será feito, bem como talvez uma revisão, ou isso será coberto por algum item anterior ao sprint ? bem como esse tipo de discussão ?

Mas ao meu ver isso seria interessante, até mesmo para saber se o sprint de uma semana é suficiente ou se seria mais interessante aumentar para duas semanas, etc...

[Joel Wallis]

Amigos, estamos nos aproximando do fim da primeira semana, período em que decidiríamos a nossa metodologia de trabalho. A única sugestão foi a minha, com a sugestão de haver sprints de 2 semanas.

A minha preferência é para uma sprint de uma semana apenas, mas com revezamento de desenvolvedores. Assim o processo anda mais rápido e não exigimos tanto dos envolvidos. Contudo, é necessário comprometimento de quem se propor a produzir o projeto.

A esse modelo tenho um aditivo: no último dia de cada sprint é feita a entrega da sprint em produção e é decidido também o(s) responsável(is) pela próxima sprint. Assim, na segunda-feira, tudo já está claro e já se pode começar a trabalhar.

E aí, alterações? Alguém contra o seguinte modelo? Será preciso votação? Teremos até domingo para definir isso.

[GMail | Thiago Régis]

Eu concordo com sprints de 1 semana, com tarefas pequenas e com revezamento de devs... Mas precisamos de uma forma de avaliar o nível técnico dos envolvidos, de acordo com a tarefa que ele está se propondo a fazer. Não dá para alguém que está começando a desenvolver em Drupal, tem que ter um mínimo de experiência.

Com certeza, para quem está começando, tem muitas outras formas de colaborar com o Drupal Brasil e ele será muito bem-vindo. Mas é dificil um cara que acabou de aprender a fazer uma View simples, já entrar em uma tarefa q requer uma View complexa (com filtros contextuais etc). Não dá pra ficar "testando conhecimentos" nesse projeto...

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[GMail | Thiago Régis]

A não ser que tenhamos uma equipe pra avaliar/testar cada feature, de cada sprint... E podendo negar alguma coisa, caso esteja muito fora "dos padrões".

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

[Joel Wallis]

Concordo completamente. O projeto que estamos nos propondo a trabalhar não é simples, nem de longe. Como podemos fazer para avaliar os que estarão se propondo a desenvolver?

Eu estou escrevendo um post para o Da Gota que reflete bem sobre a metodologia utilizada (alguns já leram e procurarei publicá-lo ainda hoje). Acredito que podemos adotá-lo e tê-lo como conhecimento necessário para estar trabalhando conosco. Trata-se basicamente de trabalhar orientado a funcionalidades (features), que possibilitará separar e organizar o projeto.

[Joel Wallis]

Também acho importante NÓS alinharmos nosso trabalho. Há vários modelos de workflow disponíveis para Drupal hoje, e alguns deles são bem legais, suprindo necessidades específicas de projetos Drupal.

O Pedro Faria me falou sobre o git-flow mas acho que ele é complexo e burocrátivo para adotar em um projeto como o Drupal Brasil. Há também o Seed da Fuse Interactive que é um script Drush que facilita o workflow deles, que parece ser mais simples e ágil.

E aí, como trabalharemos?

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

Sim, podemos nos basear no seu post como fluxo de trabalho. Mas de qualquer forma, isso não vai dar a experiência necessária a galera q quer colaborar.

Muitos dos que vão colaborar, a gente já conhece (fazem parte da lista). Mas alguns a gente não sabe como trabalha. Nós temos 2 opções:

1. Deixa qualquer um entrar pra colaborar e depois avalia o que foi feito. Se tiver bom, ótimo. Se tiver ruim, volta pra outro fazer.
• Ponto positivo: Conseguimos manter a qualidade do projeto, sem criar barreira inicial para os colaboradores.
• Ponto negativo: Se ficar ruim, teremos perdido 1 sprint para aquela tarefa. 
2. Podemos preparar testes práticos, pra equipe que vai participar da colaboração. Com alguns pequenos testes, nós conseguimos isso. Mas vamos perder tempo preparando, aplicando e avaliando os testes...
• Ponto positivo: Esses serviriam para nivelar o colaborador e para identificar o ponto forte dele (pode não ser com funcionalidade, pode ser com temas). Vamos saber os pontos fortes de cada colaborador
• Ponto negativo: Precisaria de tempo para preparar, aplicar e avaliar os testes...

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Joel Wallis]

Acabei de achar esse screencast sobre workflow Drupal com Git. Essa apresentação rolou há pouco mais de uma semana na BADCamp e parece atender às nossas necessidades. Ele é simples e prático.

Quem quiser ver o vídeo, comece vendo a partir do minuto 8 (antes disso é introdução ao Git), ou vejam os slides no post do autor.

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

boa!

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Joel Wallis]

Sou contra abrir para qualquer um entrar e desenvolver. Não por egoísmo ou outra coisa, mas por saber que uma grande parte da comunidade é composta por iniciantes. Mas se o cara souber produzir, ótimo! Mas me dói em ler o trecho "perder uma sprint!" rs.

Mas a ideia dos testes parece legal, e quem se submetesse aos testes teria a chance da auto-avaliação. Mas, sendo franco, acho que devemos evitar o excesso de democracia, espírito de comunidade e colaboratividade nesse sentido. Exagerar nessas atitudes no nosso país pode ser um grande tiro no pé para esse projeto. 1001 argumentos, e todos vocês os conhecem.

Prefiro que fique entre os reais membros do Drupal Brasil. Se começar a entrar nego irresponsável eu vou xingar tanto o FDP que vocês vão me excluir do grupo. Vou ser pior que o Pedro Rocha há três anos atrás (esse bicho era um cavalo! lembro de um carão que ele me deu uma vez por uma besteira que fiquei quase um ano sem falar nada com ele na lista).

[GMail | Thiago Régis]

Eu concordo plenamente. Também não é por egoísmo, mas para manter o controle e a qualidade do projeto.

Vamos começando com os que já participam da comunidade, que nós conhecemos. Galera que já costuma se envolver em threads (com respostas que acrescentam valor a elas)... Dos que participam, só pelo nível de diálogo, a gente sabe se o cara domina o que está falando... Então vamos nesses!

Quando vai rolar aquele hangout, pra definir os objetivos, estruturar os detalhes das funcionalidades etc? Não rola esse fds? No sábado eu vou ficar de bobeira em casa, já que minha esposa vai fazer prova. O que acham?

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[GMail | Thiago Régis]

Só pra ressaltar, pra que fique claro para todos: não estamos dizendo que somos melhores do que todos, e que vamos manter uma "panelinha" nesse projeto (já estou cansado de ouvir isso, pfffff). Só estamos dizendo que, para colaborar ativamente nesse projeto, com trabalho braçal (metendo a mão na massa mesmo), tem que dominar o Drupal! Tem que ter experiência, vivência com Drupal...

Os que ainda não tem, não estão de fora dessa reestruturação do site. Podem participar das discussões, de forma construtiva etc. Mas a mão na massa, vai ficar com os JEDIs :P

Mas com certeza cada um pode colaborar com um pouco aqui, mesmo sem ser com mão na massa ;)

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

[Joel Wallis]

Ótima mensagem, Thiago. Vamos deixá-la na wiki do Github (eu faço isso).

Sobre o hangout, sábado ou domingo? Votações, galera. Vamos escolhar até amanha qual o melhor dia. Eu voto para domingo, já que será o último dia de cada sprint, normalmente a galera não sai para encher a cara nem curtir alguma vibe mais cansativa, e domingo é um dia em que não se faz nada, então as chances de atrapalhar alguém são menores :)

[GMail | Thiago Régis]

Excepcionalmente essa semana, eu vou preferir no sábado :)

Não precisamos de uma reunião muito longa. Só precisamos definir a pauta, e não fugir dela. Se tiverem mais assuntos, e se forem muito extensos, deixamos para a outra reunião.

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Joel Wallis]

Eu estou disponível em ambos os dias para o projeto. Vamos esperar pelos votos até amanha.

[Pedro Melo]

Nao sei se perdi algo, Quais serão os critérios para seleção dos
desenvolvedores?, ressaltar que estou disponível.

2012/11/15, Joel Wallis <joelw...@gmail.com>:

>> 1. Deixa qualquer um entrar pra colaborar e depois avalia o que foi

>> feito. Se tiver bom, ótimo. Se tiver ruim, volta pra outro fazer.

>> - Ponto positivo: Conseguimos manter a qualidade do projeto, sem

>> criar barreira inicial para os colaboradores.

>> - Ponto negativo: Se ficar ruim, teremos perdido 1 sprint para
>> aquela tarefa.
>> 2. Podemos preparar testes práticos, pra equipe que vai participar da

>> colaboração. Com alguns pequenos testes, nós conseguimos isso. Mas
>> vamos
>> perder tempo preparando, aplicando e avaliando os testes...

>> - Ponto positivo: Esses serviriam para nivelar o colaborador e para

>> identificar o ponto forte dele (pode não ser com funcionalidade,
>> pode ser
>> com temas). Vamos saber os pontos fortes de cada colaborador

>> - Ponto negativo: Precisaria de tempo para preparar, aplicar e

>> http://www.rh.com.**br/Portal/Desempenho/Artigo/
>> **5841/estar-envolvido-ou-**comprometido-eis-a-questao.**html<http://www.rh.com.br/Portal/Desempenho/Artigo/5841/estar-envolvido-ou-comprometido-eis-a-questao.html>

>>
>> abs,
>> Pedro Rocha
>>
>> -------------
>> www.singleview.com.br
>> www.pedrorocha.net
>>
>>
>>
>> 2012/11/12 GMail | Thiago Régis <tregis...@gmail.com>
>>
>> Concordo com 2 semanas... a galera vai ajudar como voluntário, não tem
>> como comprometer muito o tempo deles (nosso)
>>
>> --
>> Abraço
>> Thiago Régis
>> http://fisqua.com
>> http://softfunding.com
>> Cursos Online de Drupal: http://cursos.fisqua.com
>>
>> On Monday, November 12, 2012 at 2:14 PM, Helal Ferrari Cabral wrote:
>>
>> Eu colocaria sprint de 2 semanas para nao ficar apertado hhehehehe
>>
>> Em 12 de novembro de 2012 14:10, Joel Wallis
>> <joelw...@gmail.com>escreveu:
>>
>> Amigos, vamos discutir nesse tópico APENAS O CRONOGRAMA DE TRABALHOS!
>> Vamos manter o tópico organizado.
>>
>> Sugiro o seguinte (a lista organizada reflete as semanas):
>>

>> 1. (12/11 à 18/11) organização desse próprio cronograma;
>> 2. (19/11 à 25/11) discussão sobre problemas da comunidade, possíveis

>> soluções, escolhas de funcionalidades para o projeto, definições do
>> que
>> será feito e quando será entregue (versão 1.0, 1.1, 1.2, etc), e quem
>> será
>> responsável pelo que;

>> 3. (26/11 à 02/12) organização do que já temos hoje no Github com o

>> que será feito, preparação do servidor (instalação do que for preciso,
>> criação das contas e acessos aos colaboradores, alinhamento com a
>> metodologia de trabalho;

>> 4. (03/12 à 09/12) primeira sprint;
>> 5. (10/12 em diante) pendente.

> --
>
>
>

[Thiago Régis]

Podemos decidir isso no Hangout desse fds tmb.

--

[Leonardo Silva]

Cês não tiram folga não? Tá doido... rsrsrs

Tem uma galera disponível, que se apresentou e se dispôs por aqui, que vieram falar comigo pessoalmente se dispondo, que provavelmente falaram com algum de vocês pessoalmente também.

Acho que o bom senso vai prevalecer no final. Acredito que quem se dispõe para desenvolver, no mínimo, se garante. Também correrá o risco da pessoa se comprometer e fazer mal feito ou deixar de cumprir, o que vai deixá-la "queimada" entre os principais(?) devs Drupal do Brasil.

Opinião particular: acho que se fez muito alarde, desnecessário, quanto à seleção de devs. Algum noob já se ofereceu? Só vi puta véia até agora.

--
 
 

[Helal Ferrari Cabral]

Também concordo com o Xulispa.

O ideal é só criar as demandas e deixar aberto pra quem quiser pegar. Só que se essa pessoa pegar ela tem que estar ciente das consequencias.

Abs.

[GMail | Thiago Régis]

Como sugerimos, podemos ter 2 opções: liberar pra qualquer um pegar, e avaliar o que foi entregue... ou fazer uma pré-seleção/avaliação.

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Helal Ferrari Cabral]

Tem algum local pra responder isso ou pode ser por aqui?

[Joel Wallis]

Aqui mesmo, Helal.

[Helal Ferrari Cabral]

Estava revisando todo o conteudo colocando aqui nesse topico.

Uma coisa que é preciso ficar bem claro é o seguinte:

• Que horario sera entregue as sprints? Qt tempo para entregar?
• Haverá daily? se houver como será feito?

Acho q isso tudo precisa estar documentado num google docs para quando algum desenvolver vier se volutariar ler isso tudo antes de por a mao na massa.

Abs.

[Joel Wallis]

Helal, eu sou responsável por documentar tudo isso, e irei fazê-lo na wiki do Github.

Segundo o cronograma que sugeri e que deixei aberto a sugestões e modificações até domingo, o dia para entrega das sprints será domingo. O horário ainda não defini nem ninguém sugeriu, mas acredito que seja interessante que seja feito próximo ao horário do hangout semanal.

Para o horário do hangout, acho que seria legal alguma coisa próxima do fim da tarde, umas 17 ou 18 horas. É um horário cômodo para a galera participar e acho que não influi muito nos cronogramas da galera.

Sobre o daily, na minha opinião é difícil rolar com a galera trabalhando. Acho que o que rola são discussões nas issues do Github.

[Thiago Régis]

Vai rolar o hangout esse fds ou não?

--
 
 

[Joel Wallis]

Thiago, vai rolar. Eu estarei disponivel apenas no domingo infelizmente. Se ficar para o sabado eu nao poderei participar. Gravem o video que eu irei assistir e documentar.

@Guilherme, teremos a proxima semana, a iniciar de domingo, para discutir as funcionalidades do projeto. Esses diantes que vc citou seriam para abterior a cada sprint? A proxima semana nao seria suficiente para discutir funcionalidades? Explique melhor a sua sugestao.

Aos demais, Qum podera participar do hangout?  E quando faremos, sabado ou domingo?

--
Joel Wallis

about.me/joelwallis

[Joel Wallis]

Tregis vai rolar. eu so posso no do
ingo.. que eh qdo poderei estar online. se rolar no sabdo gravem o video p eu documentar oq foi decidido.

guilherme teremos uma semana para discutir funcionalidades. vc acha q precisamos mais q isso? Explique melhor sua sugestao :)

[GMail | Thiago Régis]

Domingo qual horário?

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Gedvan Dias]

Eu também só posso no domingo, de preferência pela manhã, tipo umas 11h.

--
 
 

[GMail | Thiago Régis]

Vamos tentar no domingo então, mas só temos q definir o horário. Ideal pra mim seria por volta das 14h.

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Guilherme Hayashi]

@Joel

Minha sugestão foi exatamente essa, de discutir as funcionalidades a partir de um certo grau de abstração e ir afunilando até chegar em um nível técnico, que seja possível elencar as atividades menores e as atividades complementares. Eu havia comentado isso, pois seria interessante essa semana se repetir anterior a cada sprint, acho que é essa a idéia néh....

Acredito que um caminho assim pode reduzir a questão do nivelamento técnico que foi abordado anteriormente. Eu concordo com o pessoal de estar priorizando os devs mais experientes, pois eles podem definir um desenho do novo software melhor que pessoas que não tem o mesmo nível de experiência, mas acho que em qualquer projeto que seja colaborativo, se as atividades forem mastigadas de certa forma, além de facilitar na documentação, iria facilitar no desenvolvimento, talvez uma sugestão seria definir um padrão e fazer uma documentação de design e definir uma priorização das atividades.

Guilherme H. M. Hayashi
(19) 9204 - 1209

2012/11/17 GMail | Thiago Régis <tregis...@gmail.com>

--
 
 

[Joel Wallis]

Eu gostei da sugestao, de repetir uma semana de planejamento, ms acho que anterior a cada sprint eh plsnejamento demais e trabalho de menos :\ precisamos ser mais ageis. mas o assunto esta aberto, e que os outros envolvidos opinem.

[Joel Wallis]

Galera o hangout vai rolar q hrs? Eu to em Canoa Quebrada mas vou dar um jeito de participar nem q seja em lanh ouse. 14h mesmo? De manha eu nao garanto, mas as 14 sim. 15 seria ate melhor pq eu ja estaria em fortaleza e com internet decente.

Por favor me respondam asap para que eu me programe para oarticipar. nao vamos furar na primeira reuniao!!! Seria um descaso da mossa parte.

>>>> http://fisqua.com> --
>>  
>>  
>>
>
> --
> Joel Wallis
> about.me/joelwallis
>

--
Joel Wallis

about.me/joelwallis

[GMail | Thiago Régis]

Vamos fechar as 15 então... Só que precisamos começar pontualmente, porque as 16h eu tenho compromisso.

Qual será a pauta? Quem participará?

-- 
Abraço

Thiago Régis

http://fisqua.com

http://softfunding.com

Cursos Online de Drupal: http://cursos.fisqua.com

--
 
 

[Joel Wallis]

Discutiremos e decdiremos todos os assuntos discutidos nessa semana,por esses emails. Serao tomadas decisoes que nao foram tomadas pelos emails. Se der tempo (falaremos apenas por 1h), comentamos sobre recursos e funcionalidades e abrimos um novo topico na lista pars discuti-los.

>>>>> Acho q isso tudo precisa estar documentado num google docs para quando algum desenvolver vier se volu --

[Gedvan Dias]

Vou tentar estar presente.

--
 
 

[Joel Wallis]

Voltei para Fortaleza e já estou online.

[Joel Wallis]

https://plus.google.com/hangouts/_/0d29fd5fefbc67c26a1ac1fae8c58a0818c24c9d?authuser=0&hl=pt-BR

--
Joel Wallis

about.me/joelwallis