Design Session

07 May 2014 | Por Rafael Souza

Desing Session, também conhecida como Quick Design Session, é uma das práticas do Extreme Programming presente no dia a dia do desenvolvimento de software da ilegra.

A Design Session é um processo colaborativo de aprendizado e problematização no qual o objetivo é evoluir, iniciar ou afirmar um design de software. É importante ressaltar que, ao contrário da fase de Design proposta pelo modelo Waterfall, a Desing Session não se propõe a entender e resolver todo o problema antes da sua implementação, e sim levantar, de forma rápida, as principais variáveis envolvidas e propor um esboço que funcione como norte para o desenvolvimento.

Motivação

Essa é uma prática que lida diretamente com os aspectos de manutenção e flexibilidade do software, melhorando a qualidade e, por consequência, a velocidade de entrega do software. Além disso, a Design Session trabalha sob uma visão diferente da codificação e é um ótimo momento para os desenvolvedores buscarem um melhor entendimento do que será desenvolvido e proporem possíveis soluções para o problema em questão.

As Design Sessions, seguidas de revisões, também podem ser utilizadas como um meio de melhorar algumas habilidades dos desenvolvedores, tais como: capacidade analítica e de abstração, comunicação com PO e com o time, entendimento geral do sistema e problematização.

Como aplicamos na ilegra

As Design Sessions são aplicadas por um desenvolvedor ou em equipe, de forma rápida, em no máximo 30 minutos, embora por vezes despendemos mais tempo.

Quando é feita por um desenvolvedor, este centraliza a comunicação com o Product Owner (afim de elucidar requisitos) e submete o esboço de sua solução à uma revisão (Design Review). Além disso, esse desenvolvedor fica incumbido de fazer um briefing explicando sua solução para a equipe que irá trabalhar no problema proposto.

Quando é realizada em equipe, a Design Session é mais dinâmica e colaborativa dispensando revisão e briefing, e nesse caso, os requisitos já devem estar mais claros ou o Product Owner estar junto à equipe.

A prática de Design Session, geralmente é aplicada por User Story e trabalhada em duas etapas cíclicas. Em uma dessas etapas olhamos para o contexto do problema: variáveis, requisitos, natureza da informação, componentes envolvidos, participantes e etc. A outra etapa envolve a parte mais técnica do design de software e o ponto fundamental é esboçar a solução que vai nortear o desenvolvimento, nesta etapa estão envolvidos: design patterns, SOLID, trade-off, algoritmo, estrutura de dados, composição de componentes, entre outros.

O que aprendemos

Com a nossa experiência aplicando essa prática aprendemos que o nível de abstração que deve-se chegar no esboço do problema está mais relacionado ao próprio problema do que a alguma regra ou técnica. O que deve ser buscado é que o time "pegue a ideia" da solução proposta e, para tanto, algumas caixas desenhadas em um caderno mostrando relações e responsabilidades de componentes, por vezes, é o suficiente.

Embora seja comum vermos diagramas de classes e componentes como resultados das Design Sessions, o uso ou padronização de linguagens de modelagem e ferramentas não é obrigatório. O principal objetivo dessa prática não é documentar software, e sim, visualizar o problema e comunicar um esboço de solução ao time. Aqui na ilegra, geralmente utilizamos cadernos, quadros e cacoo como ferramentas. Já a linguagem de modelagem gráfica surge sozinha a partir dos gostos e experiência dos times e, na maioria das vezes, ela é um misto de UML, CRC e muita criatividade.