Day: Mar 29, 2019

I have completed my very first Unreal and C++ tutorial! I am very pleased with this simple game as it is a significant milestone for me and is the first fully functioning project that I have been able to put together. Now before anyone shouts ‘but it was just a tutorial, anyone with eyes and fingers could have done that!’. That’s true. They could have. But here’s the good part (for me at least). I understand it.

Not much more than a little while ago, there would have been no way that I would have looked at something like this and thought, yeah, I see whats going on there. I didn’t know basic C++ so following Unreal ‘version’ of it was painful and not really possible. This problem came about mainly due to the learning curve that I would have had to experience while on the BA Top Up course. I could not learn about the Unreal editor, Blueprint (which even when using C++ needs to be understood and used) and then a mighty language like C++ over the top of all that. I just would not have been able to produce anything worth showing.

Since graduating from the course, I still felt that learning the code in C++ would be too much of a challenge and so I resigned myself to working in Blueprint only while carrying on the development of Serial Link. It was not really until I was experiencing the reality of thinking about what would happen if Serial Link did not work that I thought, oh dear, I still cant code in anything but a very specific tool for a very specific engine.

So, shortly before taking on this MA, I grabbed a course on Udemy that I have already covered here, and started the climb to coding stardom. Ok, that’s a touch over the top, but you know what I mean. I thought about Unreal and C++ together and thought that I would save myself a ton of headache’s if first, I got used to the C++ language on its own and then stepped into the fray with Epic, the makers of Unreal. I expected that I would be able to break into coding for Unreal once I understood a little bit more about the language itself and for the most part I’ve been right. I think that I am ready to start a C++ project in Unreal or, and this may be a better move, refactor some of the logic in Serial Link into C++ one small feature at a time. I would rather have something to show for it at the end that I could use professionally.

I have been interested in this sort of thing. I mean that I have been interested in finding some structure to the place that is just a step back from the Kanban board, just a bit further away. I find that when I think about planning for a project, I think in a blend of ‘wouldn’t it be cool if’ and ‘we need to implement’. I have a good grasp on breaking down the implementation side of things but I think that I could benefit from learning a bit more about structuring the part of the project that leads to how the user should interact with some feature and how they should feel about it. That last one, ‘feel about it’ is very important to me as I already understand that games, once boiled down, are really all about feelings.

The MA content requested that I watch the video on Personas from the Pluralsight course ‘Creating Effective Stories’ and upon having watched it, I think that I could get a lot of benefit from watching the whole course, so thats what I am going to do.

Thinking in Stories

• A user story is a placeholder for a conversation. Thats a great quote and is really helping me to understand what this is about.
• Design is deferred to the Last Responsible Moment giving the team the time to find out as much as possible about the real requirements.
• The key to the flexible, high level story is that it is an encouragement to the team to interact with the customer and find out more about the requirements as the quickly implemented builds are delivered.
• Its important to remember that you should define Acceptance Criteria as the first step of starting development work on the story. Note that the Acceptance Criteria should be created and confirmed before any coding begins. More on that later.
• Users Stories: The 3 Parts
  • 1. As a …
  • 2. I want to …
  • 3. So that …
  • This tends to reduce frivolous requirements that can be created using a feature list.
  • As a player, I want to be able to shoot bad guys, so that I can level up and get more abilities.

Types of Stories

• What are Roles?
  • They represent groups of users rather than individuals
  • They are derived from the characteristics of the group
  • From the example
    • Users – Customers
      • Dont use the word ‘users’ in encompasses everyone really
    • Service People
    • Owners
• How to evaluate the stories using INVEST
  • Independent
    • Independent: They are self contained and don’t rely on other stories. This is very useful due to the fact that User Stories may/will need to move around in the backlog, changing their prioritisation. Its useful if there are not another set of stories that have to move because of that. I can imagine that in game development this may be difficult as one system builds on another but I am keen to see how this can be resolved. It actually links in a little to the Single Responsibility principle in terms of how I should think about it.
  • Negotiable
    • Negotiable: This means that they should be available for change as the true requirements are honed in on, but that it should stabilise as the team get closer the Last Responsible Moment before implementation begins
  • Valuable
    • Valuable: This makes sure that the story has real value to the User defined in the story, removing superfluous requirements and wishful thinking from the backlog and therefor the application. This also prevents the occurrence of too many technical requirements and makes sure that there are ‘downstream’ benefits to the User defined in the story.
  • Estimate-able
    • Estimate-able: The team should know enough about the story and it should be small enough so that they have a good idea of the work involved in delivering it. Note that if it is not Estimate-able, a Spike story may be required. I talk about this later.
  • Small
    • Small: This is linked in with the ability to estimate the work required to implement the story and serves to reinforce that its scale is directly related to that outcome.
  • Testable
    • Testable: The story should be defined enough so that developers could define tests that could be used to prove that the value in the story is being delivered or be able to highlight where that is not the case.
• Epics
  • This is a User story that is too large to be completed without further breakdown into separate stories and consideration of its dependencies. An Epic could be the story that describes the entire value proposition, overlaps several smaller stories or is just too vague due to the assumed, smaller activities that would be required to have it work properly.
  • What are the qualities of an Epic?
    • The Epic story captures a complete workflow towards a goal, and can be broken done into the beginning, middle and end.
    • Its not deliverable until all the stories are complete
    • For a game that Epic might be something like: As a player, I want to experience a great story and complete the adventure using puzzle solving skills, so that I can experience satisfaction when I reach the end.
• Themes
  • Themes are a way the think about stories that are related but don’t need to be completed together. This is the crucial difference that makes them different to Epics, in which the Epic is not delivered until each story is complete. A good example the presenter gives is performance. In games that could relate neatly to delivering a high FPS lets say. There may be multiple areas of the game to consider while completing this work but each part of the game can contribute to the improvement in performance individually, which would make the collection of stories a Theme and not an Epic

Personas

• What are they?
  • What is a persona? Its a fictional character that can represent a person that is going to use the product we are developing. They are different from Roles, covered earlier as they represent groups instead of individuals and can give the roles depth. The development team should be able to relate to the invented persona more easily with an aim to getting closer to what the customer wants from the product. Create personas for roles that are coming up in conversation frequently.
• Relationship Mapping
  • This allows a visual representation of who is using the product. It can identify new users and their influence on the product. It also shows the interactions between the users to reveal insights about what each of the users, or roles, need from the system and that should lead to a better design.
• Choosers Vs. Users
  • Choosers are the ones that are paying for the system
  • Users are the people that will be, yep, you guessed it, using it.
  • Im game development, this could be the publisher vs the player. The publisher would want financial return from the ‘system’ (game in this case), and the player (user) wants the fun. Its common that the needs of the choosers are placed above the need of the user as the choosers have greater influence on the system at the time of design and are the ones signing it off. This can be frustrating for the poor user/player and cause the product to fail as without users, whats the point?
• How to create a Persona?
  • Give them a name, a photo (of a real person doing something that matches the feeling they should get from the product), which Role they belong to and a description of what they want to get out of the product. You can also include a ‘key quote’ from the user that explains what they want. If appropriate you could add a title and demographic information. Dont use pictures of celebrities, the team will already have preconceived ideas about who that person is. Make sure that the Personas are visible to the team and keep them up to date should their needs change.

Splitting Stories

• Why would you need to split it?
  • Larger stories are more difficult to estimate, can be too narrow in expertise required causing one person to have the bulk of the work and can be much more noticeable if not completed on time.
  • Smaller stories offer more flexibility, are easier to negotiate with the product owner and can save a lot of work as the additions to the story that were planned may never actually be needed in the end.
• When might you want to split a story?
  • When the team gets nervous about estimating completion times.
  • When the proposed completion times and the actual times dont match.
  • When the number of Story Points reaches some number, say 3. I didn’t know anything about Story Points and have found another resource I hope to cover here soon.
• How to split stories?
  • Vertically
    • Don’t split the task ‘horizontally’ meaning that you should not define a story like ‘build database’ if there is also a UI due. Better to define a story ‘vertically’ which allows some database and some UI to be built so that the team is left with an ‘end to end’ piece of work when its completed. This would also be easier to test as its a complete feature at this point and allows the team to maintain their flexibility demanded by Agile. But it can lead to an initial drop in productivity as team members have to learn about areas of the project that they are unfamiliar with.
  • Finding Seams
    • A Seam is an logical separation with a larger story. There are a few different types presented here and they are:
      • Workflow
        • This is good for when there are many steps in the workflow ,move to weapon, select weapon, equip weapon, target with weapon, fire weapon and so on…
      • ‘illities’
        • These are the qualities of the product that are not so obvious. For instance
          • Security
          • Reliability
          • Scalability
      • Positive and negative cases
        • Splitting the story along whether some action in the system is successful or not. The example given is successful vs. failed login attempts. In a game it could be getting to the end of a level, having outstanding tasks and being able to notify the user.
      • Third party dependencies
        • This makes sense if there are other external parties involved who are not part of the core team or who are remote. The example given is that of a UI artist who will only be focused on that part of the product. This also makes sense as contractors will be less influenced by the core teams day to day needs and changing priorities and more concerned with delivering the work that was agreed within some previously agreed window or deadline.
      • Roles
        • This one is straight forward and is just splitting up the story based on the roles, or stakeholders within it. The only consideration is that the new stories should not rely on each other.
      • Spikes
        • A Spike is a special case of story that is useful when the team is tackling a story that requires some skill or technology that the members of that team are unfamiliar with. Because of this lack of experience, its not possible for the team to give a good estimate on how long the work will take to complete. A Spike story can be created that uses time boxing and allows the developers a chance to explore the problem with the specific goal of learning enough about how it will be solved that they can give a completion time estimate.

Getting to Done

• Meeting the expectations
  • Customer
    • The customer will require qualities from the product such as it being easy to use, reliable, meeting the latest specification, clearly adding value and so on. This is implemented using Acceptance Criteria which are best extracted from the product owner using conversation and questioning. These can be created along with the story and can be written on the back of a sticky for instance.
    • Acceptance Criteria
      • This allows the team to go back to the high level user story and fill in the gaps to make it more detailed and specific. As mentioned above, they should be created as the first step in actually executing the story and should be fully accepted before development work begins. The format for this is
        • Given
          • What has to have happened in the product first, what is the prerequisite?
        • When
          • Some particular action happens
        • Then
          • Some expected result
      • Given that the Soldier is patrolling, when the Soldier sees the player, then the Soldier shoots at the player.
      • How to get it right
        • Be specific and make sure that everyone is clear about what the criteria means. They should be measurable so that the team and the customer are clear when a criteria has been met. It must be realistic and within the scope and constraints of what the team can deliver.
  • Developer
    • This allows the team to be happy that the features are robust and easy to maintain and develop in the future. The Acceptance Criteria are often called ‘Done Rules’ and are also common on Kanban boards, I have some of my own on the Serial Link board. These should be created by the team, allowed to evolve, be made public and kept informal which encourages the feeling that they can change if needed.
    • Done Rules Common Examples
      • Testing
        • Has the code gone through automated testing and passed.
      • Peer reviewed
        • Has someone other than the original developer looked at the code or was it pair programmed.
      • Deployed
        • Is it staged checked in for deployment and have the changes to the core code base been made if any are required.
      • Has the Product Owner reviewed the feature and agreed that it meets their expectations.

In Conclusion

I really got a lot of value from this course and have a much clearer understanding of how to set up an Agile project from the perspective of the value that needs to be delivered rather than the tasks that need to be completed. Although I found the course a little dry, the content was worth the time. I will keep these things in mind for the next project that I find myself in.