Em continuidade à série Filosofia ágil, cujo objetivo é apresentar artigos sobre metodologias de gestão e desenvolvimento de softwares, veremos hoje a segunda parte da abordagem sobre a Getting Real. O artigo inicial pode ser lido aqui.

Equipe de trabalho

Simplicidade e foco na execução são alguns dos pilares fundamentais do processo Getting Real. Isso se aplica também às equipes de trabalho sugeridas pela metodologia.

Conforme citação do livro Getting Real, uma equipe de três pessoas pode ser ideal para a concepção da primeira versão da aplicação. Bons profissionais são fundamentais, e vale ressaltar que a polivalência é bastante comum nos ambientes de trabalho de hoje.

Uma equipe de três pessoas não deve ser interpretada como uma dimensão fixa, tampouco indicada para todos os projetos que se pretenda executar com a Getting Real, cabe a cada gestor adequar-se. Os autores da metodologia justificam a manutenção de equipes pequenas pelos consideráveis ganhos em flexibilidade nas mudanças de rumo, agilidade, além da facilidade de comunicação.

Começando a produzir

“Vá do brainstorm a esboços, a HTML, à codificação”. É o que ditam os autores da metodologia no livro Getting Real.

Primeiramente, devem ser discutidas e determinadas as ideias referentes ao que se pretende produzir. Sem aprofundamentos detalhados, é hora de relacionar o que se espera do projeto. Os detalhes entrarão em pauta no momento condizente.

Em seguida, devem ser transferidas as ideias filtradas no brainstorm para rascunhos de interface ou que representem o fluxo das ações que serão desempenhadas pela aplicação. Não se faz necessário o uso de recursos avançados de desenho. É importante que seja possível chegar a conclusões sobre o que foi esboçado.

Novas definições terão sido obtidas a respeito das interfaces que farão parte do projeto. Com isso, pode-se partir para a criação num formato executável, HTML e CSS por exemplo, sem programação neste ponto, apenas para que seja possível prever como o software será apresentado ao usuário. A incorporação da programação deve ser realizada após todas as etapas anteriores terem sido concluídas com sucesso.

Esta fase do processo deve ser encarada como um conjunto de atividades iterativas, além de interativas. Quando se perceber que algo deve ser repensado, retorna-se para a etapa antecessora. É bastante comum que haja retornos durante estas definições. Decisões equivocadas podem ter sido tomadas e, comumente, fazem parte do trabalho.

Seleção das funcionalidades

As funcionalidades sugeridas para a aplicação devem passar por uma crítica análise de viabilidade, sempre mantendo foco na visão do projeto. Saber o que é essencial e o que pode ser descartado é a chave para se obter bons resultados com o produto.

Devem ser considerados também os esforços para manutenção de cada funcionalidade embutida no software, afinal de contas, essa responsabilidade é de quem a concebeu, e todo o conjunto de funcionalidades do software deverá funcionar em sintonia.

Trabalhe nos detalhes na hora certa

É comum no cotidiano profissional deparar-se com situações que exijam um tempo a mais para serem resolvidas, principalmente quando focamos nos detalhes. Algoritmos complexos e criação de designs geralmente estão cheios de minúcias.

A vida de um software é bastante longa, ao menos deveria ser. Portanto, os detalhes podem ficar para outro momento. Dessa forma, quando se está iniciando a elaboração de um projeto de software com a Getting Real, a etapa destinada à criação das interfaces e a suas funcionalidades deve visar ao cumprimento das necessidades primárias que permitirão o uso de tais interfaces.

Após um razoável período de utilização, possivelmente serão detectados vários pontos que requerem uma maior atenção. Eis então a hora certa para atacá-los e alinhá-los ao contexto de cada aplicação. É bem provável que se observe a ausência de funcionalidades importantes ou sacadas interessantes de ergonomia e de usabilidade.

Testes devem ser reais

Outro mantra da Getting Real está relacionado à fase de testes do software, e dita que “[…] não há substituto para pessoas reais usando sua aplicação de maneiras reais. Pegue dados reais. Receba feedback real.”.

Testes reais são apontados como mais reveladores que os testes de laboratório, pois são direcionados a situações inerentes do ambiente onde está inserida a aplicação. Sugere-se que quando se está sob observação, como nos laboratórios de testes formais, o comportamento desempenhado pelo usuário é bastante premeditado.

Quando for possível, a publicação de versões beta do software são bastante indicadas. Dessa forma, o uso do software se dará com usuários e dados reais. É indispensável a disponibilização de um ou mais canais de comunicação de fácil acesso para o recebimento de feedbacks dos usuários beta.

Continue acompanhando

No próximo artigo, o último da série sobre Getting Real, serão descritos temas sobre a etapa de entrega do projeto, interessantes estratégias pós-lançamento, além do processo de manutenção e suporte do produto, contemplando desde a comunicação com o usuário até ideias para o treinamento e a capacitação dos clientes.

Contribua com seu comentário!