Muito se lê e, eventualmente, alguma coisa se escreve.
Então, colocando em prática antes que ocorra o vazamento entre os neurônios, traduzo (e reduzo) aqui o artigo Process Agility and Software Usability: Toward Lightweight Usace-Centered Design, do nosso camarada Larry Constantine.
Visão Geral
O artigo traz o termo “Centrado no Uso”, e isso pode ser visto também como aquilo que o Eric Evans diz no início do seu livro Domain Drive Design, que nada mais é do que:
Faça modelos quando for necessário e onde for melhor, e não mais do que isso.
Cara, isso é perfeito.
Mas o que quer dizer isso mesmo? Vamos lá...
OS MODELOS são nossos diagramas em geral, casos de uso, atividades, colaboração, deployment and so. Não precisam ser necessariamente UML, mas se forem, melhor. Pode ser texto, pedaços de código em linguagem de programação ou pseudo-alguma-coisa, ou então... bem, qualquer coisa que faça o Destino (equipe) entender a origem (cliente e projetista).
A NECESSIDADE vem do objetivo. Se o prazo é curto, então nada de CASE, mas sim quadro branco (adoro), papel de pão, tabletPC, screenshot de tela rabiscado and so. Se o cliente exige formalismo (e claro, se vai pagar por isso – por exemplo, software para NASA ou alguma Telecom), então a CASE vai bem. Se nossa metodologia é burocrática (diga-se de passagem, implementamos um MPSbr, CMMI ou algo assim), então não basta a CASE, e precisamos um JIRA (rastreabilidade), Subversion (gerência de configuação), Atas de reunião (Plano de Comunicação no PMBOK) e por aí vai. Então, isso é a necessidade.
O MELHOR pode ser entendido com uma função f(x) = Satisfação do Cliente (PMBOK) versus Modelos versus Necessidade, ou seja, é como aquela história da importância dada a um risco de projeto, que equivale à sua probabilidade x impacto...
Parece complicado, eu sei. E por isso que a leitura do artigo original pode ajudar bastante...
No tocante às seções do artigo, ressalto os pontos mais relevantes abaixo.
Agilidade em Excesso
Muita agilidade não é bom. Quem o diga são os físicos, que ainda hoje brigam nos aceleradores de partículas para tentar compreender as coisas...
Então, a máxima aqui é: seu ambiente precisa ser tão ágil quanto for necessário para cumprir a (famosa) satisfação do cliente. E, novamente, não mais do que isso.
Práticas xiitas (essa eu copiei de ti Poletto) não são bem vindas de forma alguma. No meio termo entre XP e Agile UP, um FDD vai muito bem. Então, nosso 3PUP está legal.
Escalabilidade Falha
Lockwood é enfático em dizer que, de forma geral, equipes ágeis não escalam facilmente. E aqui, podemos encontrar pessoas que vão discordar. Eu não discordo dele porque (1) li o artigo e vi os porquês e (2), ainda não conheço nenhuma equipe de 300 pessoas ou mais, atuando de forma distribuída e que usam exclusivamente processo ágeis puros.
O Scrum (e não conheço muito bem outros processos) fala em “Scrum of Scrum”. Mas isso não se aplica aqui, pois Scrum (assim como todas práticas ágeis) é muito balizado pelo conceito de proximidade e galera pegando junto. Quanto mais um projeto cresce, menor é este fator.
Nesses casos, a alternativa mais viável ainda é burocratizar o processo e exigir documentação e controle. Assim, a agilidade diminui, mas o projeto continua...
Arquitetura de IU
De forma geral, excetuando sistemas compostos por grupos clusterizados de servidores, as aplicações geralmente necessitam uma arquitetura básica, onde geralmente 3 são as mais importantes na arquitetura do sistema:
Então, colocando em prática antes que ocorra o vazamento entre os neurônios, traduzo (e reduzo) aqui o artigo Process Agility and Software Usability: Toward Lightweight Usace-Centered Design, do nosso camarada Larry Constantine.
Visão Geral
O artigo traz o termo “Centrado no Uso”, e isso pode ser visto também como aquilo que o Eric Evans diz no início do seu livro Domain Drive Design, que nada mais é do que:
Faça modelos quando for necessário e onde for melhor, e não mais do que isso.
Cara, isso é perfeito.
Mas o que quer dizer isso mesmo? Vamos lá...
OS MODELOS são nossos diagramas em geral, casos de uso, atividades, colaboração, deployment and so. Não precisam ser necessariamente UML, mas se forem, melhor. Pode ser texto, pedaços de código em linguagem de programação ou pseudo-alguma-coisa, ou então... bem, qualquer coisa que faça o Destino (equipe) entender a origem (cliente e projetista).
A NECESSIDADE vem do objetivo. Se o prazo é curto, então nada de CASE, mas sim quadro branco (adoro), papel de pão, tabletPC, screenshot de tela rabiscado and so. Se o cliente exige formalismo (e claro, se vai pagar por isso – por exemplo, software para NASA ou alguma Telecom), então a CASE vai bem. Se nossa metodologia é burocrática (diga-se de passagem, implementamos um MPSbr, CMMI ou algo assim), então não basta a CASE, e precisamos um JIRA (rastreabilidade), Subversion (gerência de configuação), Atas de reunião (Plano de Comunicação no PMBOK) e por aí vai. Então, isso é a necessidade.
O MELHOR pode ser entendido com uma função f(x) = Satisfação do Cliente (PMBOK) versus Modelos versus Necessidade, ou seja, é como aquela história da importância dada a um risco de projeto, que equivale à sua probabilidade x impacto...
Parece complicado, eu sei. E por isso que a leitura do artigo original pode ajudar bastante...
No tocante às seções do artigo, ressalto os pontos mais relevantes abaixo.
Agilidade em Excesso
Muita agilidade não é bom. Quem o diga são os físicos, que ainda hoje brigam nos aceleradores de partículas para tentar compreender as coisas...
Então, a máxima aqui é: seu ambiente precisa ser tão ágil quanto for necessário para cumprir a (famosa) satisfação do cliente. E, novamente, não mais do que isso.
Práticas xiitas (essa eu copiei de ti Poletto) não são bem vindas de forma alguma. No meio termo entre XP e Agile UP, um FDD vai muito bem. Então, nosso 3PUP está legal.
Escalabilidade Falha
Lockwood é enfático em dizer que, de forma geral, equipes ágeis não escalam facilmente. E aqui, podemos encontrar pessoas que vão discordar. Eu não discordo dele porque (1) li o artigo e vi os porquês e (2), ainda não conheço nenhuma equipe de 300 pessoas ou mais, atuando de forma distribuída e que usam exclusivamente processo ágeis puros.
O Scrum (e não conheço muito bem outros processos) fala em “Scrum of Scrum”. Mas isso não se aplica aqui, pois Scrum (assim como todas práticas ágeis) é muito balizado pelo conceito de proximidade e galera pegando junto. Quanto mais um projeto cresce, menor é este fator.
Nesses casos, a alternativa mais viável ainda é burocratizar o processo e exigir documentação e controle. Assim, a agilidade diminui, mas o projeto continua...
Arquitetura de IU
De forma geral, excetuando sistemas compostos por grupos clusterizados de servidores, as aplicações geralmente necessitam uma arquitetura básica, onde geralmente 3 são as mais importantes na arquitetura do sistema:
- Uma estrutura essencial para que todas as IU sigam um padrão;
- Um esquema comum e versátil de navegação entre as IU e suas partes integrantes;
- Um esquema de interação entre usuário e IU que seja consistente e orientado à tarefas do usuário (os casos de uso do sistema).
Finalmente, teria mais texto, mas agora é quase meio-dia, e tenho que almoçar...
Então, como dica, leiam o cara em:
http://3layer.org/ebook/Modelagem,UML,Metodologia,GerenciaDeProjetos,PMI,PMBOK,Scrum,FDD,Agile,Requisitos,Requirements/Agile Design - Larry Constantine - Lockwood - 2002.pdf
Saiba Mais
Acesse o site http://foruse.com
Então, como dica, leiam o cara em:
http://3layer.org/ebook/Modelagem,UML,Metodologia,GerenciaDeProjetos,PMI,PMBOK,Scrum,FDD,Agile,Requisitos,Requirements/Agile Design - Larry Constantine - Lockwood - 2002.pdf
Saiba Mais
Acesse o site http://foruse.com
0 comentários:
Postar um comentário