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.
-
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.
-
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
Muito interessantes suas colocações! Seguem algumas observações:
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.
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.
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
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.
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:
[quote]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.[/quote]
:arrow: 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 ?
:arrow: 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 ?
:arrow: Existe uma quantidade mínima e/ou máximo de integrantes no time para adotar um método Ágil?
:arrow: Quanto tempo deve levar uma Sprint ?
:arrow: 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!
[quote=lina]
Alguém já fez algo parecido ? A falta de comunicação é comum na empresa onde vocês trabalham ?
Tchauzin![/quote]
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
Vou responder com minha opinião:
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.
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.
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.
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.
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…
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!
[quote=Guerr@]
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![/quote]
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!
[quote=lina]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 [/quote]
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.
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!
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
Conforme já dito pelo pessoal, a falta de comunicação é um grande problema em muitas das empresas de software.
Mas gostaria de acrescentar mais um: a falta de disseminação de conhecimento, que pode ou não ser consequência da falta de comunicação.
Trabalhei numa empresa onde tinhamos sessões técnicas de 1 hora por semana. Nessas sessões alguém era responsável pela apresentação do assunto (que poderia ser um “post-mortem” de algum projeto, o uso de novas tecnologias ou até mesmo soluções de modelagem do domínio). Posso dizer que aprendi muito com essa prática, pois o conhecimento não ficava “represado” em uma só pessoa. Dessa forma, a montagem de equipes para os projetos era facilitada.
Fica a dica.
Essa é uma excelente prática! E digo mais: talvez a pessoa que prepara a apresentação acaba aprendendo mais do que quem assiste.
=> A melhor forma de aprender é ensinar! 
[quote=lina]Oi,
[quote]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.[/quote]
[/quote]
Tive a grande oportunidade de trabalhar com arquitetos dos 2 tipos… gostei tanto de ter trabalhado com arquitetos ágeis que saí de uma empresa com menos de 2 meses de trabalho tendo com um dos grande motivos o fato de o arquiteto se encaixar perfeitamente na definição de “arquiteto tradicional”.
[quote=fantomas]…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…[/quote]
aí o agente de mudança e os outros podem exercer outra qualidade (“valor ágil”): a coragem.
é preciso coragem para mudar, e isso pode ser insentivado e exercitado.
[quote=lina]
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![/quote]
Lina,
Tenho umas dicas pra vc:
:arrow: não adicione uma coluna no quadro, remova uma simplifique… tire termos de inglês, chame a secretária ou a tia do café e pergunte se ela entende o que representa o quadro… se ela entendeu, então está simples!
:arrow: talvez a sua reunião diária está demorando muito… e por isso a reclamação… pra vc fazer uma conta mais ou menos… calcule que uma pessoa fale de 30seg a 1min , uma equipe de 10 não costuma demorar mais que 7minutos.
:arrow: procure fazer as reuniões sempre no mesmo horário (Exemplo: 10h) e obrigue o seu chefe a participar (pra ele é bom pois não precisa perguntar depois o que cada um está fazendo, é só ele escutar a equipe).
:arrow: force as pessoas a manter o quadro atualizado, no começo é complicado , mas depois a equipe percebe que isso é importante. Se o seu chefe quiser saber como tá indo, é só ele olhar o quadro, não precisa interromper ninguém.
:arrow: adicione no quadro tb o gráfico de convergência (burn-down), é ele que dá a visão geral se vocês estão atrasados ou não em relação ao Sprint inteiro
Boa sorte!