[MJ 50] Como você lida com arquitetura no projeto ágil da sua empresa?

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Olá pessoal!

Esse mês a edição da MundoJ foi dedicada a práticas de arquitetura no contexto de métodos ágeis.

Aproveito a oportunidade para perguntar: que práticas vc usa na sua empresa para lidar com a arquitetura?

Saudações!

Nas duas últimas empresas foi + ou - como descrito na matéria, embora tenha lido apenas uns 70 % do conteúdo.

Tanto nas empresas percebi 2 coisas que aparecem em forma de obstaculo para quem está na "liderança" do projeto.

1) Conciliar a espectativa da equipe em relação as inovações tecnológicas.

a) Normalmente a espectativa da equipe é aprender mais e se possível sobre coisas novas na nova empreitada, mas nem sempre isto será bom para o projeto. Acredito que seja neste momento que surgem soluções mirabolantes ao invés de uma solução simples e corriqueira.

2) Dependendo do número de componentes na equipe pode ocorrer:

a) Demora em decidir a arquitetura a ser adotada devido as divergencias de idéias - isto pode parecer simples mas na minha opinião não é, grande parte da equipe pode ficar desmotivada devido a estrategia adotada.

b) Após iniciado o projeto se fazer cumprir com o combinado e ainda assim tendo que ter a mente aberta para uma possivel melhora na arquitetura acordada sem afetar as espectativas de prazos com ganhos relevantes.

Enfim não sei se a matéria apontou estes detalhes e não percebi; mas são coisas que surgiram nos últimos projetos que participei.

flws

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Muito interessantes suas colocações! Seguem algumas observações:

fantomas wrote:Conciliar a espectativa da equipe em relação as inovações tecnológicas.

Acho que as inovações tecnológicas tem sim seu lugar, mas com foco em aumentar a produtividade da equipe ou resolver algum problema arquitetural. O momento de se definir a arquitetura inicial com uma User Story Experimental seria um momento para se testar diferentes abordagens e valida-las. Durante o projeto, pode-se utilizar Design Spikes (uma prática muito usada em XP) para pensar a respeito da adoção de uma nova tecnologia ou abordagem.

fantomas wrote: Demora em decidir a arquitetura a ser adotada devido as divergencias de idéias - isto pode parecer simples mas na minha opinião não é, grande parte da equipe pode ficar desmotivada devido a estrategia adotada.

Acho que é por isso que a arquitetura deve ser validada e testada por todos. Se existem outras alternativas (daí falando de design e não usar o framework X ou Y), elas devem ser experimentadas e avaliadas sob o ponto de vista dos requisitos mais relevantes. Caso sejam equivalentes, a mais simples deve ser escolhida. Se houver dúvida, isole aquela parte para que possa ser trocada mais tarde de forma mais simples se necessário. Dessa forma, a decisão deixa de ser a opinião do Fulano e passa a ser algo que foi experimentado e avaliado por todos.

Legal esta pergunta passei por esse dilema algumas semanas atrás.
Acredito que fundamental é você sentir quanto a sua equipe está madura para adotar uma nova tecnologia e quão qnto eles irão comprar essa idéia.

This message was edited 1 time. Last update was at 28/11/2011 09:54:51

Legal esta pergunta passei por esse dilema algumas semanas atrás.
Acredito que fundamental é você sentir quanto a sua equipe está madura para adotar uma nova tecnologia e quão qnto eles irão comprar essa idéia.

Ops falha do GUJ.....posts duplicados

Obrigado pela resposta Guerr@, concordo com o que disse.

Estranhamente poucas pessoas estão comentando este tópico, será isto um indicador de que arquitetura é um assunto pouco discutido dentro das empresas?

Me fêz lembrar dos posts sobre DDD, o assunto "pegou fogo" e depois não se falou mais p#%%@ nenhuma kkkk.

flws

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

ramilani12 wrote:
Acredito que fundamental é você sentir quanto a sua equipe está madura para adotar uma nova tecnologia e quão qnto eles irão comprar essa idéia.

Na verdade, acho que a solução deve ser a mais adequada e não somente a que a equipe tem maturidade. A maturidade de equipe em uma determinada tecnologia deve ser um dos fatores a serem considerados, porém não pode ser o único.

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Oi,

Primeiramente gostaria de dar os parabéns por esta excelente edição da revista.

Tenho alguns comentarios e também algumas perguntas e quem sabe esclarecê-las com a ajuda de vocês.

Levando em consideração o texto abaixo:

Arquitetos Tradicionais

* São seres "diferenciados". Suas opiniões são verdade absolutas.
* Estão sempre "muito ocupados" para colocar as mãos no desenvolvimento do software.
* Se acham tão "diferenciados" que gostam de prever o futuro para não terem problemas.
* Investem muito tempo em criar modelos arquiteturais com "todas" as informações possíveis.

Arquitetos Ágeis

* São humildes e buscam soluções conjuntas
* São membros ativos do time de desenvolvimento, ajudando na codificação e atuando como mentor.
* Sabem que não podem prever o futuro, mas podem estar preparados para ele.
* Sem desperdicios. Focam em relatar o que é util e importante naquele momento.

Devo ter em meu time integrantes que possuem múltiplas habilidades? Ou cada integrante deve conhecer de apenas uma ou até duas área em especifico ?

Posso levar em consideração que o mais experiente e mais completo membro do time, deve exercer o papel do arquiteto principal ? Este membro deve ser um líder ou gerente do projeto ?

Existe uma quantidade mínima e/ou máximo de integrantes no time para adotar um método Ágil?

Quanto tempo deve levar uma Sprint ?

Poderiam citar exemplos de organizações que trabalham com modelagem ágil ?

Na empresa onde trabalho, estamos tentando adotar algum procedimento ágil. Ao contrário do que diz na revista, estamos utilizamos o CVS para armazenar a documentação e as planilhas de desenvolvimento (priorizando certos itens a serem feitos). O grande detalhe é que quase ninguém vê essa planilha, apenas no final do dia. Isso gera algum transtorno, até porque alguns funcionários iniciam certas tarefas nas quais já estão sendo feitas por outro integrante da equipe. Alguém tem alguma sugestão ?

Agendei para a primeira semana de janeiro um TEAL (Treinamento Experencial ao Ar livre), onde é trabalhado os assuntos:

- Sinergia
- Comprometimento
- Resultados coletivos
- Trabalho em equipe
- Auto-confiança
- Liderança
- Gestão de riscos
- Planejamento
- Tomada de decisão
- Administração e controle sobre pressão
- Confiança

Alguém já fez algo parecido ? A falta de comunicação é comum na empresa onde vocês trabalham ?

Tchauzin!

JWizard Membro desde: 23/02/2007 15:52:55 Mensagens: 2034 Offline

lina wrote:
Alguém já fez algo parecido ? A falta de comunicação é comum na empresa onde vocês trabalham ?

Tchauzin!

Oi,

Comentando apenas sua última frase, a falta ou falha de comunicação é sempre o PRINCIPAL problema nos lugares onde trabalhei..

Nunca a tecnologia foi um problema tão relevante quanto..

Abs

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

Vou responder com minha opinião:

lina wrote:
Devo ter em meu time integrantes que possuem múltiplas habilidades? Ou cada integrante deve conhecer de apenas uma ou até duas área em especifico ?

Eu acho que o perfil ideal é alguém que seja o Especialista/Generalista: ou seja ele tem um conhecimento mais profundo em algumas áreas, mas também possui um conhecimento mais geral sobre o resto. Se as pessoas não forem assim, dê incentivos para criar esse perfil na sua equipe. Exemplo: dando treinamentos gerais para todos (podem ser palestras internas por exemplo) e dando espaço para cada um se desenvolver na área q tem mais interesse.

lina wrote:
Posso levar em consideração que o mais experiente e mais completo membro do time, deve exercer o papel do arquiteto principal ? Este membro deve ser um líder ou gerente do projeto ?

Isso depende muito da equipe. Por mais que exista a figura do arquiteto, as outras pessoas da equipe devem compreender e participar de atividades relacionadas a arquitetura para estarem comprometidas com ela.

lina wrote:
Existe uma quantidade mínima e/ou máximo de integrantes no time para adotar um método Ágil?

Na verdade não, mas as práticas que você precisa apra gerenciar uma equipe grande, são diferentes das práticas apra se gerenciar um equipe pequena.

lina wrote:
Quanto tempo deve levar uma Sprint ?

A resposta padrão seria de uma semana a um mês. Porém se você implementar um ambiente de continous delivery, você pode ter um ambiente onde são feitos vários deploys diários em produção.

lina wrote:
Poderiam citar exemplos de organizações que trabalham com modelagem ágil ?

Citar nomes é complicado... Se quer algo para mostrar as pessoas na sua empresa, sugiro procurar artigos de Experience Reports em eventos como WBMA, Agile, SPLASH e etc...

lina wrote:
Na empresa onde trabalho, estamos tentando adotar algum procedimento ágil. Ao contrário do que diz na revista, estamos utilizamos o CVS para armazenar a documentação e as planilhas de desenvolvimento (priorizando certos itens a serem feitos). O grande detalhe é que quase ninguém vê essa planilha, apenas no final do dia. Isso gera algum transtorno, até porque alguns funcionários iniciam certas tarefas nas quais já estão sendo feitas por outro integrante da equipe. Alguém tem alguma sugestão ?

Coloque as informações na parede onde ele á visível a todos! Quadro branco, postit e etc... Faça uma reunião diária curta para cada um dizer o que está fazendo, o que vai fazer e que dificuldades estão o impedindo de continuar seu trabalho.

Espero ter ajudado!

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Guerr@ wrote:
Coloque as informações na parede onde ele á visível a todos! Quadro branco, postit e etc... Faça uma reunião diária curta para cada um dizer o que está fazendo, o que vai fazer e que dificuldades estão o impedindo de continuar seu trabalho.
Espero ter ajudado!

Oi,

Foi exatamente isso que eu fiz. Coloquei um quadro grande na parede com as colunas: Priority| To do | WIP | DONE (Em To do, quebrei em varias tarefas o que está em Priority)

Mesmo assim, nem sempre as pessoas seguem a risca esse quadro. De inicio meu superior perguntou se eu estava brincando de escolinha. Agora, ele sempre olha o quadro para verificar os serviços pendentes.

O quadro ajudou muito, porém falta alguém para "puxar" a orelha do pessoal e fazer com que todos sigam o planejamento do Quadro (Quem sabe esse não seria o papel do Arquiteto ?!). Criar metas e prazos de entrega para cada item priorizado seria algo interessante ? Como expor isso no quadro? Criar mais uma coluna?

Tchauzin!

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

lina wrote:Mesmo assim, nem sempre as pessoas seguem a risca esse quadro.

O quadro ajudou muito, porém falta alguém para "puxar" a orelha do pessoal e fazer com que todos sigam o planejamento do Quadro

Vejo isso acontecer quando as pessoas não entendem a importância do quadro e os conceitos que estão ali por trás! Em desenvolvimento ágil, para haver o comprometimento, as pessoas devem endender os valores. Não é só seguir o processo! Talvez muitos não levem muito a sério pois encaram as coisas como seu chefe no início. Minha sugestão seria dar um treinamento de para o pessoal entender o motivo daquele quadro. Muitas vezes esses treinamentos só fazem efeito se vem alguém de fora dar o curso, pois quando é alguém da própria empresa, muitas vezes não é levado muito a sério.

Tentou as reuniões diárias? Talvez elas sejam um bom momento em que todo dia cada um atualiza seu status.

Moderador Membro desde: 23/12/2006 21:05:04 Mensagens: 3083 Offline

Oi,

A principio, reuniões diárias é perda de tempo. Esse é o pensamento das pessoas aqui.

Consegui no maximo adotar reuniões a cada "Sprint". Toda sexta-feria.

Vamos por partes como diria Jack. O próximo passo então será conseguir reuniões diarias.

Tchauzin!

Virtual Machine Man Membro desde: 03/12/2006 10:32:50 Mensagens: 520 Offline

lina wrote:
A principio, reuniões diárias é perda de tempo. Esse é o pensamento das pessoas aqui.

Como havia dito, acho que o próximo passo seria fazer as pessoas entenderem os valores por trás das práticas... Sem isso eles vão apenas seguir o processo de maneira cega e esse é o primeiro passo para uma implantação de ágil não dar certo.

Parabens lina pela iniciativa, esforço e principalmente coragem em tentar implantar algo, pelo que entendi novo no local onde vc trabalha.

Concordo em gênero, número e grau com que o Guerr@ escreveu, só gostaria de adicionar que em uma forma bem mais ampla o que vc está querendo fazer, na minha opinião, é alterar a forma de trabalho das pessoas independente de ser para melhor ou pior (espero que não rsrsr); uma especie de processo de mudança.

Neste caso o promotor da mudança sempre irá encontrar indiferença, ódio, opiniões contrarias frequentes, motivação, euforia, altas expectativas, frustrações, insegurança e etc... perceba que a parte negativa da lista normalmente não é claramente verbalizada pelos participantes. Se o promotor tiver poder sera mais fácil de aplicar a mudança porem será mais dificil perceber os indicadores dos resultados da mudança; infelizmente nos dias de hoje na maioria dos casos é dificil (mas não impossivel) provocar uma mudança sem um pouco de poder nas mãos.

O que muitos esquecem é que os resultados são obtidos pelas ações das PESSOAS, a maneira como eles serão obtidos nasce nas mãos das pessoas os livros trazem sugestões, na maioria das vezes boas sugestões o problema é que as vezes as boas sugestões não se encaixam a determinados grupos de pessoas.

- Por que as pessoas acham que reúniões diarias é perda de tempo?
a) É por que demora muito?
b) As pessoas divagam muito e não chegam a lugar algum?
c) Querem sabotar a mudança?
d) O reúnião é mal elaborada, portanto confusa e improdutiva.
e) etc...

- Alguem para "puxar a orelha". Qualquer um, em um grupo de pessoas comprometidas, que acredita no que faz, com boas intenções e que caminha na mesma direção pode e saberá quando, como e onde "puxar a orelha", em uma situação ideal essa pessoa não sofrerá riscos pois todos sabem que ela esta preocupada com os resultados do projeto.

Enfim, minha intenção é alertar que, por traz das metodologias, principalmente as àgeis, existem muitas coisas importantes implicitas que normalmente são negligenciadas ou mesmo não comentadas por vários fatores que geralmente faz parte do comportamento humano. Se manter frio e atento a estes fatores podera ajudar muito na minha opinião.

Tente detectar aqueles que na sua opinião ainda "não compraram a idéia" e procure saber o porque. Talvez eles tenham uma boa resposta. Se as respostas forem boas (honestas e que fazem sentido) talvez vc tenha que adaptar a metodologia ou corrigir a aplicação desta. Se forem ruins (falsas) tente convence-los da melhor forma possivel de que a metodologia é boa se não houver sucesso talvez não seja uma boa idéia a participação deles na sua nova proposta.

flws

flws

Notícias, artigos e o maior fórum brasileiro sobre Java