Desenvolvimento Ágil de Software guiado pelo Design de Jogos.
- English Agile Software Development guided by Game Design
Após muitos anos de insatisfação com a aplicação de forma descontextualizada de diversas maneiras (UML, BPMN, Agile, etc) de fazer o design e desenvolvimento de sistemas informatizados, resolvi expressar em código uma forma contextualizada de desenvolvimento visando contemplar formas de design de sistemas.
Hoje os métodos ágeis já formalizaram uma forma gameficada de pontuar e avaliar o desempenho dos desenvolvedores através da pontuação por User Stories. Um sistema é definido através de histórias dos usuários e a carga de trabalho é quantificada com base em estimativas de esforço de programador/hora. Esse design é fragmentado em fases classificadas como Sprints e Releases, que juntos quantificam o Backlog do projeto. Esse é um jogo de estratégia aberto, com regras de jogo flexíveis (como por exemplo a definição de "Pronto"), e várias regras do jogo de desenvolvimento são definidas à partir do método de trabalho escolhido e adaptado por cada equipe que trabalha no design do sistema. Apesar de tudo disso, a gameplay acaba quando o sistema é projetado e arquitetado através de formas diferentes de abstrair o mundo real que está sendo digitalizado.
Neste momento, eu apenas estou descrevendo como a abstração do mundo real pode se aproveitar da maneira como os Desenvolvedores de Jogos enchergam as abstrações de mundo. E estou tentando demonstrar como o gameplay pode resultar em sistemas também interpretados como jogos. Essa metodologia, ao abstrair a digitalização de sistemas em jogos, transforma o desenvolvimento de sistemas em desenvolvimento de jogos da vida real.
Pode parecer um pouco confuso agora devido ao método de abstração do mundo ainda não ter sido descrito para você. Mas, tenho certeza que esta forma de interpretar os requisitos dos sistemas fará com que nenhum desenvolvedor da sua equipe tenha mais dúvidas (ou, pelo menos diminuirá significativamente as dúvias) sobre como modelar o sistema e como planejar as entregas em Sprints, Releases ou de forma contínua.
Vejamos agora como a sua percepção sobre um usuário do sistema será amplificada quando você o visualizar como um jogador. E como fará sentido descrever suas ações como habilidades durante o Contexto de um Cenário. Eu sei, você já deve ter muitos anos de experiência fazendo isso. Mas, pode ter ficado perdido diversas vezes ao esperar que uma Funcionalidade fosse bem definida pela equipe. Pode também ter tido muitas dores de cabeça quando o cliente do projeto mudou o fluxo da Sprint, e se deparou com o tisunami de intervenções devido a aquele requisito não estar bem isolado, quando foi definido, dificultando a análise do impacto das mudanças. Mas, provavelmente vai ficar entusiasmado com a facilidade de explicar que os requisitos de um módulo do sistema correspondem às fases de um jogo. Se o módulo não for bem definido, a fase vai poder funcionar de forma incompleta. Vai poderá também resignificar quando o avanço do projeto for encarado como o lançamento de novos items de um jogo. Todos ficarão com a consciência tranquila e renderão mais. Afinal, qualquer mundo de jogo evolue e qualquer jogador fica ansioso para receber as novas funcionalidades do jogo.
After many years of dissatisfaction with the application in a decontextualized way in different ways (UML, BPMN, Agile, etc) of designing and developing computerized systems, I decided to express in code my contextualized form of development in order to accommodate a large amount of design. of systems.
Today, agile methods have already formalized a gamified way of scoring and evaluating developers' performance. A system is defined through user stories and workload is quantified based on programmer/hour effort estimates. This design is broken down into Sprints and Releases. Several rules of the development game are defined based on the work method chosen and adapted by each team working on the system design. Despite all this, gamification ends when the system is designed and architected in a way based on different ways of abstracting the real world that is being digitized.
Right now, I'm just describing how the real-world abstraction can take advantage of the way Game Developers fill the world abstractions that result in a game in ways that can also result in systems understood as games.
It may seem a little confusing now because the world abstraction method has not yet been described to you. But, I'm sure that this way of interpreting the systems requirements will make no developer on your team have more doubts (or at least significantly reduce doubts) about how to model the system and how to plan deliveries in Sprints, Releases or continuous way.
Now let's see how your perception of a system user will be amplified when you visualize him as a player. And how it makes sense to describe your actions as abilities during the Context of a Scenario. I know, you must have many years of experience doing this. But, it may have gotten lost several times when waiting for a Feature to be well defined by her team. It may also have had a lot of headaches when the project client changed the sprint flow, and was faced with the tisunami of interventions due to that requirement not being well isolated when it was defined, making it difficult to analyze the impact of the changes. But, you'll probably be thrilled with how easy it is to explain that the requirements of a system module correspond to stages in a game. If the module is not well defined, the phase will work incomplete. It will also be able to resign itself when the advancement of the project is seen as the release of new items for a game. Everyone will have a clear conscience and will yield more. After all, any game world evolves and any player is eager to know what's new.