Arquitetura da Informa��o (em Portugu�s)

[Christiane Melcher <chrismelcher AT gmail.com>]

Fred e Pessoal,

Já que estamos numa pegada da história da coisa, complementando a informação sobre a indústria de automóveis, teve um artigo sobre games que foi muito importante. Colei aqui um pedaço de um texto que falo do Scrum:

"Em 1986 Takeuchi e Nonaka publicaram o artigo “The New New Product Development Game” na Harvard Business Review explicando que eles notaram que projetos usando equipes pequenas e multidisciplinares (cross-functional) produziram os melhores resultados, e associaram estas equipes altamente eficazes à formação do Scrum no Rugby.

Jeff Sutherland, John Scumniotales, e Jeff McKenna documentaram, conceberam e implementaram o Scrum, na empresa Easel Corporation em 1993, incorporando estilos de gerenciamento observados por Takeuchi e Nonaka. 
Em 1995, Ken Schwaber formalizou a definição de Scrum em um congresso da ACM. Esse foi o lançamento formal que ajudou a disseminar o Scrum para empresas de desenvolvimento de software de todo o mundo...."

Para quem quer ler mais sobre o conceito na indústria de automóveis, sugiro a leitura do livro dos livros da Toyota. Tem o "Toyota Production System: Beyond Large-Scale Production", o "Modelo Toyota" e outros.

Sobre o designer projetar pensando no micro, acho que só dessa forma dá para encaixar no planning do sprint. Por outro lado, a visão do todo, por mas que seja algo que pode mudar, é importante para que o produto não se pareça com uma colcha de retalhos. Dependendo do tamanho do produto, do quão inovador ele é, o sprint zero/discovery, que não fazem parte da cultura ágil e das "regrinhas", é fundamental para ajudar nessa visão do todo inicial, sem muito detalhamento. O mapa de histórias se encaixa bem nessa fase. Também sou a favor do designer e AI trabalharam pensando no que vem um pouco a frente e se dividindo com as demandas pequenas burocráticas do sprint. O problema disso é que o PO também precisa estar com essa visão do que vem a frente, por mais que de repente possa mudar, mas que já permita o pessoal de UX começar a pensar nessa experiência de uso antes de chegar o dia do planning.

Técnicas mais ágeis como  mind map, conceptual map, sketches, user secenarios, paper prototyping, personas etc podem ser muito úteis nesse cenário.


Abs,
Chris

Em 30 de setembro de 2011 09:35, Frederick van Amstel <usabilidoido AT gmail.com> escreveu:

Carlos, permita-me discordar.

Os princípios básicos de agile development, SCRUM, XP, Kanban e outros não surgiram no desenvolvimento de software. São conceitos importados, principalmente, da indústria automotiva. Essas indústrias desenvolveram métodos ágeis para poder entregar o produto o mais rápido possível e diminuir o tamanho do estoque. Para quem gazeou as aulas de Geografia do Ensino Médio, o nome disso é just-in-time.

O just-in-time se deve à aceleração do capitalismo. Quanto mais rápido viera o retorno, melhor. Por isso os produtos de hoje são feitos mais rápidos, vendem mais rápido e quebram mais rápido do que os antigos. É claro que o único que se beneficia desse ciclo é o próprio capital e não as pessoas.

Agile development se deve à maturação das fábricas de software que, frente ao (óbvio) fracasso do taylorismo aplicado a software, tiveram que se adaptar. O resultado certamente não será software de melhor qualidade, e sim mais do mesmo. E isso não é visto como um problema, pois a demanda por aplicativos especializados baseados em padrões universais é gigantesca.

Eu acredito que as fábricas de software não vão dar conta da demanda por agilidade, que vai crescer ainda mais. Acredito muito mais no desenvolvimento localizado baseado em plataformas customizáveis. Esse movimento a indústria automobilística já fez há algum tempo, usando a mesma base com diferentes carcaças, peças compartilhadas, acessórios.

Uma das coisas que estou pensando em falar na palestra é sobre o papel do designer nesse contexto. Se ele tenta projetar todas as telas que saem da produção, ele vai estar sempre atrasado, empatando o trabalho de todo mundo. É preciso pensar a experiência do usuário num nível mais macro.

Um papel possível para o designer é projetar essas plataformas customizáveis. Inicialmente dentro da empresa, como patterns, toolkits, guidelines e posteriormente fora da empresa, como produtos modulares, DIY kits, treinamentos. O designer delega o design e se responsabiliza pelo metadesign.

Nessa perspectiva, o uso desses recursos por desenvolvedores sem formação em design pode ser considerado design também, mesmo que não haja uma metodologia. A metodologia é praticada por osmose pela interação com a plataforma.

Já vi algumas pessoas apontando esse caminho, mas poucos mostraram como fazer isso na prática. Por isso decidi fazer um doutorado para pesquisar esse fenômeno, que estou chamando de Design Livre.

Soa interessante?


Em 29 de setembro de 2011 18:25, Carlos Kramer <kramer.carlos AT gmail.com> escreveu:

O assunto é realmente interessante. 

Duas impressões minhas:

1 - entre método ágil e o manifesto ágil há uma abismo. Conversei isso com alguns amigos desenvolvedores que advogavam o agil, mas se desencantaram com os desdobramentos, e eles concordaram com essa visão. O simples fato de ter virado um "método" já é a antítese do manifesto.

2 - o método ágil é obra de desenvolvedores, voltado para desenvolvedores. A aplicação dele ao processo de Design é uma espécie de "aberração" (palavra um pouco exagerada, eu sei), e vai especialmente na direção oposta do design centrado em pessoas. 

Se pudéssemos condensar ao máximo numa frase bem simples e curta o que é Design, eu talvez optasse pela frase "antever, pensar antes de fazer". Sem querer abusar da etimologia, "projetar" é exatamente isso, lançar-se para frente, projetar-se para frente, antever problemas e especificar soluções (e por especificar me refiro inclusive ao design de uma interface, por exemplo). O agile, por sua vez, se simplificado em bom português, é mais ou menos isso: "vai pensando e fazendo, no fim a gente vê no que deu".

Ao aceitar a filosofia ágil (que é uma filosofia de desenvolvimento, não de design), a gente abre mão de boa parte das premissas do ato de projetar. É nesse ponto que ouvimos sempre o mesmo argumento: "software não é carro, não é navio, não é prédio, é mais fácil e barato de modificar, etc". Isso é verdade, mas acho que pouca gente se questiona se isso é bom. A pergunta mais importante nesse caso acho que é: o agile propicia produtos finais melhores? Melhores para quem? Se pensamos em softwares como produtos, não seria o caso de aprendermos um pouco com os processos de design de produtos, e com todo o resto do conhecimento humano sobre "projetar". 

Não sei se já conhecem, mas sugiro um texto do Bill Buxton sobre o assunto:

Performance by Design: The Role of Design in Software Product Development

http://www.billbuxton.com/SoftwareDesign.pdf

A crise de identidade do Design atrapalha bastante nisso. O meu mantra pessoal é "Design é muito mais do que UX". Mas esse é outro assunto. :)

Abraços,

Carlos Krämer

+55 (21) 9803.2408

Site | Linkedin | Twitter

Em 28 de setembro de 2011 18:40, Frederick van Amstel <usabilidoido AT gmail.com> escreveu:

Caros,

Estou preparando uma palestra para o Intercon sobre desenvolvimento ágil e procuro relatos de equipes e profissionais da Experiência do Usuário que estejam trabalhando em ambientes de Desenvolvimento Ágil.

Até o presente momento, as equipes com que já tive contato me relataram que o modelo do Garrett (Estratégia > Escopo > Estrutura > Esqueleto > Superfície) não funciona para esse tipo de ambiente. É preciso fazer adaptações nas metodologias tradicionais de UX para encaixar com o desenvolvimento ágil.

Alguém gostaria de compartilhar um relato na lista ou em PVT sobre esse assunto?

Agradeço de ante-mão.

--
.
.{ Frederick van Amstel }.
http://fredvanamstel.com

Faber-Ludens Interaction Design Institute
http://www.faberludens.com

. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt

--

::: Ao responder, elimine o texto não essencial de mensagens anteriores :::
***************************************************************************************
DesInterac - comunidade mantida pelo Instituto Faber-Ludens, uma entidade sem fins lucrativos que promove a integração do Design e da Tecnologia no Brasil.
 
Novidades em http://www.faberludens.com.br
Cursos em http://cursos.faberludens.com.br
Projetos abertos em http://www.corais.org
--
Você recebeu esta mensagem porque se cadastrou no Grupo "DesInterac" do Google Groups.
* novos tópicos pelo email desinterac AT googlegroups.com
* cancelar a inscrição http://bit.ly/a2Tfoo
* outras opções em http://groups.google.com/group/desinterac

--
.
.{ Frederick van Amstel }.
http://fredvanamstel.com

Faber-Ludens Interaction Design Institute
http://www.faberludens.com

. . . . . . . . . . . . . . . . . . . . . .
Ao responder, elimine o texto não essencial
de mensagens anteriores e evite formatação.

Lista de discussão AIfIA-pt
AIfIA-pt AT lists.ibiblio.org
Arquitetura de Informação em Português
http://lists.ibiblio.org/mailman/listinfo/aifia-pt