Jump to content
  • Advertisement


  • Content Count

  • Joined

  • Last visited

Community Reputation

1065 Excellent

About paulecoyote

  • Rank

Personal Information


  • Twitter
  • Github
  • Twitch
  • Steam
  1. Nice to see you @Khawk :)  I actually logged in again!
  2. paulecoyote

    Yayy, ranting about languages!

    First post in a long time, but this article made me smile :0)
  3. Many thanks to Ryan at industrybroadcast.com for recording one of my articles. It is very flattering to have been approached and amazing to be able to download a podcast with my own words read back to me on the subject of Agile Vocabulary. Perhaps I should read aloud new articles to myself to make sure they are friendly to that format! I have another article in draft that I started on the Bank Holiday Monday and will try and finish that over the weekend. If anyone has a subject they might want me to try and cover suggest it and if I can I will over the next few weeks. Orginally posted at paulecoyote.com
  4. Background This is the start of a series of articles about agile development. The motivation behind writing these articles is to expand my knowledge of the topic by explaining how I currently understand it. I imagine feedback from readers about their own experiences and understanding of the topics discussed could help my own comprehension of the material. This entry focuses on some basic vocabulary used in the project management side of agile practices. The vocabulary presented here concentrates on requirement gathering, describing deliverables and estimation and will be used in later articles in this series. My Experiences The game team I am currently on use scrum (though purists would called it "scrum but") which is common methodology adopted for managing time on an agile project. I have myself used "agile" style development practices like unit testing and continuous integration (using NUnit, Cruise Control .Net and Trac) in my past life outside of the games industry. I have made sure to make time to read about these agile practices for years. Most of the week beginning 8th of February 2009 I took part in a lab called Agile Development in C# and I had a glimpse of techniques used in teams around the mother-ship. Spending the week building a project, managing the backlog and taking turns at being the scrum master and team lead was a very educational experience. "Living it" with guidance in this way was like a crucible of learning (there was an element of competition too). It was very rewarding yet quite draining! My current lead developer attended the same course - thus I am more confident about "buy-in" of some agile practices at that level because of the extra common ground that brought me. I have already had the opportunity to apply some development techniques discussed in that course to the main code base I work with day to day. Vocabulary: User Stories User stories are requirements written from the perspective of the customer. A collection of user stories make up the "product backlog" and can be prioritised by how important they are to the user. This allows the developer to concentrate on things that would be immediately useful to the customer for when a vertical slice of the product is delivered at the end of the "sprint". A user story is an expression of what they want and why, rather than any technical detail of the how. A good example might be: "I would like my lawn to be short so it is pleasant to lay back and read in the garden." A poor example might be: "Mow lawn to 2 cm using a rotary petrol mower." The user stories concentrate on requirement gathering and intent. These stories help communicate how the development team understand the requirements. They also allow quick feedback from the user on any good or bad assumptions made. Vocabulary: Story Points Story points were introduced as a way of quantifying an estimate of a user story. Where as estimates are usually expected as a duration, story points are based on an estimation of size and complexity. For example a gardener might want to estimate the size of the lawn, see how overgrown it is and how much edge work would be necessary to keep it neat before attempting to estimate a time. Depending on weather conditions on the day, it may even take slightly longer on some days than others. The customer expects a regular fee and period of time spent in the garden rather than taking in to account difficulties from one week to the next. One week the garden may not have grown very much and the whole thing will be quicker to complete. Perhaps the gardener might take the time to make nice little extra touches to the garden to add value that easier week where there is ample time left over. So a story point is not directly translatable to time because of the various unknowns. The number of story points against something keeps track of how much effort will be required - something with more story points is harder to complete. Vocabulary: Tasks Tasks are derived from breaking a user story down in to small chunks of functionality. These tasks are estimated in hours (or story points). The estimated time remaining is updated daily during the scrum. A task is only counted as "done" when it is verified. A consistent measurement of "done" is important so it can be signed off for the sprint. Quality gates can be used to measure if something is actually complete. This could include passing tests and automated code quality tools. Once all the tasks for a user story have been completed, functionally tested and verified, then it can be taken from the product backlog. For example tasks for large garden could be (in the form of Task (verify) - duration): Mow lawn (lawn appears visibly shorter. Regular straight lines can be seen in the grass) - 2 hours Tidy garden and rake lawn (no debris can be seen on the lawn or path, grass cuttings bagged and loaded) - 1 hour Vocabulary: The Daily Scrum The Daily Scrum is often a short morning stand-up meeting only including people doing the work itself. The scrum master role can be taken up by any member of the team. The scrum master asks the questions: What did you do? What will you do today? What is blocking you? The estimates are updated on the current tasks, and the scrum master goes about trying to unblock the team where they are blocked. Blockages could be something technical, through to waiting on another team to complete a task. Continuing the gardening example - if the gardeners have noticed the lawn mower blades have become blunt and causing the team to slow down, it would be up to the scrum master to communicate with the tools team and ask them to sharpen the lawn mower blades. Vocabulary: Sprints A selection of user stories are chosen for the sprint. Stories can be added or dropped from a sprint, but the deadline for a deliverable does not change. If the deliverable, demonstrable version of the software is created ahead of time and the team feels confident they can take another story from the backlog and if it's too big, break it down where possible. The idea of a sprint is to always have something to show for the work everyone has done at a regular interval, to allow the users to feed back. At the point a sprint begins, the requirements of the stories they are working on are locked. A sprint can be completely aborted, or a story dropped... but the requirements of an existing story should not change. The motivation is that the team are not aiming for a moving target and can concentrate on getting the unit of work done. Ideally each sprint delivers a vertical slice to show progress. For the running gardening example I have been using - this might be completing the more simple front garden entirely to prove the gardeners have understood the requirements sufficiently to maintain the garden to the customer expectations. It also gives the customer an opportunity to feedback or change their mind "actually, I want my lawn to have circles rather than lines". Vocabulary Cheat Sheet Daily Scrum: Short stand-up meeting. What did you do? What will do today? What is blocking you? Product backlog: Prioritised list of user stories. Quality gate: Checklist of things to verify work against before it is counted as completed. Scrum master: Leads daily scrum. Tracks work completed and remaining, and organises removal of things blocking the team. Ideally a role rotated between members of the team. Sprint: A period of time where user stories are chosen to work on. External influences are not allowed to change the requirements of the stories being worked on. Sprints are a fixed length, but stories can be postponed or additional ones taken from the backlog. Story points: Unit of estimation measuring complexity. Task: A user story can be broken down in to one or more tasks. Tasks are estimated daily in hours (or story points) remaining by the developer working on them. User stories: User requirements expressed in sentences from the customer perspective. Vertical slice: Showing off a feature in an application that works from start to finish but may be limited in scope. For example a rope bridge crossing a chasm is immediately useful and allows people to cross. Having that in place can help to build a better bridge later. References Some of my references are company confidential and cannot be shared here - the web is full of useful information though. The sites below are useful launch pads to further reading. Agile manifesto clearly states the priorities of an agile developer: http://www.agilemanifesto.org/ Wikipedia has a good overview of scrum and vocabulary discussed here: http://en.wikipedia.org/wiki/Scrum_(development) Pragmatic Programmers (I've been a fan of their books for quite some time): http://www.pragprog.com Jeromy Walsh via Joel Bennett's blog for subconsciously planting the idea of a rope bridge I used in my vertical slice definition. Agile game development site: http://www.agilegamedevelopment.com/ Laura Brandau's blog about her experiences with Agile development: http://www.bridging-the-gap.com/ Andy Barton recommended this to me the other day, but have not had a chance to look at it yet: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches Please comment any useful links you have stashed away :-) This entry was first posted to my external blog here: http://paulecoyote.wordpress.com/
  5. paulecoyote

    Book book book bookety book!

    Congrats, an amazing achievement!
  6. paulecoyote

    Latest Screen

    very pretty!
  7. paulecoyote


    Liked the visual studio colour scheme you showed a while back. It's interesting reading your thought processes on how you are developing [smile]
  8. I have read a few blogs recently about the industry, how the authors got in and what they think about what is going on right now... I figured I would add my voice to the discussion. The news is full of stories about so many closures and layoffs everywhere and the games industry is not immune. Studios are shedding jobs through publishing deals falling through, bills not being paid or a change of focus and direction. I am acutely aware of how fortunate I am being employed in times like these. Some companies are quite well known for a high level of churn, especially during the final stages of shipping a game and straight after. Some of this is natural - people leaving for new opportunities of their own choice and looking for a change or promotion. Others have contracts that are due to end and do not get renewed - where as this is difficult for the employee at least it is predictable and they can look for work in advance and perhaps have a financial plan in place. Salaried employees not expecting the chop, contracts terminated prematurely... those people have it the worst. When you are unexpectedly on the job market, there are all kind of pressures that wouldn't exist if the move was your choice - least of which might be competition for a position with a former colleague. Staff with experience are harder to come by though, and job descriptions for all but the most junior positions seem to expect it. Some programming jobs do put game industry experience down to preferred rather than required. A high rate of churn means many transient candidates in the recruitment talent pool - it is probably easier to get hired elsewhere at a higher level than to get internally promoted at many companies. Indeed for an open senior position, it may make sense to hire someone from outside because they are proven in the role or because the company has money for the new hire-possibly due to this coming from a different budget from the promotions budget. The company knows that they have someone in the wings capable of the title, but may not be likely to reward that position or money to the individual in question while they are content to stay in their current role. I have only been in the game industry for just over two years - I came over from the business/government software sector where I had worked my way up to being the lead programmer on a few products. Ever since I was a little kid I had always wanted a credit on a game, so I did not pass up the opportunity to move in to the industry when it came up. I'm proud to say I have achieved that ambition - not just on any game - but a successful game. I worked on a bug here and there for Fable II, but my aptitude and experience from my previous life meant I was employed as part of the tools team. Working on the tools team might not be a glamorous part of the process, but it still can be very rewarding. Your customers are internal and you can immediately see when you improve their day. As far as career structure goes - I think many software engineering roles in games or business software sometimes require you to jump ship and move around from time to time. Indeed some of the most senior people at Lionhead have moved around pretty frequently before settling there. People who have left Lionhead tend to do well - a "standard" programmer left recently to become a technical director elsewhere - quite the career leap. The Media Molecule guys are also prime examples of excellent alumni - setting up their own company and publishing a game that garners so much critical acclaim is an impressive feat. Owning or being a partner in a company is something I see for myself in the long term future. Having your own future in your hands is appealing because although there is relative safety working for someone else responsible for you getting paid - it does not stop a decision high up in the chain of command resulting in your job position being eliminated. I do not want to leave Lionhead anytime soon though - I feel I have much more to give to the studio - the skills and experience I have are uncommon in the games industry. For those wanting to get in to the industry despite how turbulent it seems to be - my advice would be to pick something to specialise in and be able to demonstrate it in some way. For students, remember that university is a game itself - where often the grade is the first thing people notice, then the subject and the institution it came from. When you are starting your university programme, think seriously about what goals you hope to achieve from your course. What are your strongest skills? What skills do you feel you have the most potential to develop? What are your biggest weaknesses? Make sure you choose a mixture of options which help you to maximise your strengths, develop the areas you know will benefit you the most, and challenge the weaknesses without destroying your final grade. Do not over commit yourself trying to face subjects addressing the areas where you are least capable - keep this in mind especially in the final year when choosing your dissertation / final year project - there are going to be many pressures on your time. While it is important to build those areas up, it is just as vital to be the best you can possibly be at the things that come more easily to you. It is important to dedicate personal time to build up your own portfolio so you have something to show other than university course work. As for picking the degree itself - if you are a programmer a games degree might not necessarily be the best thing - a good computer science / math degree plus being able to show your own side projects might put you in an even stronger position. A traditional degree adds flexibility to your career too... if the games thing does not work out you have a good basis for plan B. Just as I have made the leap over to games, I have known some game developers that have migrated over to business and banking software. If you cannot get in to the games industry straight after university do not despair - just make sure you are working in something where the skills might be transferrable in to the game industry and get some experience under your belt. It is very important to get real life experience because even the best university course is still academic and reality is often a little different. Besides, a really good, open minded studio might later see something in you that they want [smile] Every day I come in to work I see something new and inspiring - and to be in the company of such talented and visionary people is an honour. Being here and learning from those around me is good for my future, and no doubt will open up opportunities for me later on in my career. Lionhead is hiring... apply via me if you are interested! [grin] (this is a repost from http://paulecoyote.wordpress.com/)
  9. paulecoyote

    Sketching Software Trial - Introduction

    You are a student / teacher right? You could probably get a good discount on Expression Design 2. A little while ago the excellent blog Lost Garden did some work on Space Cute using Expression.
  10. paulecoyote

    Innate to Pirate?

    I think PC Gaming is just going to have to shift to advert driven - if it's "free" then perhaps that would stop some forms of piracy... though I'm sure someone would come up with a advert removing patch. The Xna Creators Club may offer small companies and lone gunman a way of getting some money via the Xbox 360 though - a platform that actually requires hardware alteration to successfully pirate a game on but open enough to be published on once the game has gone through a peer review process.
  11. paulecoyote

    Three sides good, four sides bad.

    The coolness continues! [smile] Well came across this open source 8-bit console and figured if you haven't seen it, you should! http://www.hackszine.com/blog/archive/2008/11/fuzebox_open_source_8bit_game.html?CMP=OTC-7G2N43923558
  12. paulecoyote

    BBC BASIC's improved filling, *EXEC and Lights Out

    Thanks for taking the time to blog this stuff, I always find it fasinating [smile]
  13. The Fable II team is going to London tomorrow... I know I haven't had much time to hang out here recently (for obvious reasons) but for those that know me if you want to meet up here are the details [grin]
  14. paulecoyote

    Grill Simulator 360

    LOL @ avatar customisation - at one point is she topless?!
  15. paulecoyote

    Bank-Switching Memory and I2C

    Thanks for documenting this... I look forward to the next installment!
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!