Jump to content
  • Advertisement
Sign in to follow this  
doeme

What is your definition of done?

This topic is 1820 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts


So in this case a definition of "done" as "Functionally complete, with all images and layout" would have prevented the whole discussion.

 

These kinds of things are communication issues.  If the project tasks are completed but the feature isn't really "done" then there may be some room for improvement in the task description and requirements gathering and documentation.  For something like this, depending on the size of the project, of course, it may help to have a developer that is the final say on tasks.  They know everything about the software, so they know what every feature should do.  Call it "Scrum Master" or "Point of Contact" or "bellybutton", but they are responsible for closing the task when finished.  

 

I worked for one boss long ago who was obsessed with the word "done."  No one could ever figure out what his definition was, but he wielded like Thor's hammer.  If software that had been deployed for six months broke and had to be fixed, he'd scream "I though you said it was done!  Why are you still working on it."  

 

This process of gathering requirements and creating software out of nothing, while managing so many different people, personality types, and areas of expertise, takes time to evolve.  Make sure you have AARs (after action reviews) to evaluate your process.  If something wasn't actually done, but everyone thought it was, figure out why.  Was there something you could have done to see the problem?  Is there something that could be done differently next time?

Share this post


Link to post
Share on other sites
Advertisement


First, never let a developer who has wrote a feature to write a test case for it. The test case must be written for someone else before the developer starts to work. If the developer tells someone what to test, then the tester is useless. The developer is biased and will never think of testing some stuffs (say, put a 10000 letters text inside a "Username" input field). It's not because he's a bad programmer or he's stupid, but the developer is trying to make something work and all his effort is into that.

 

This is not possible if  you have a really small team.  I worked for years where there were many projects and only 5 programmers.  Each person was completely responsible for multiple projects.  Most of the developers didn't have tests for anything.  The just hacked the code and prayed it would work. 

 

Also, test driven development is based on doing exactly the opposite of what you're describing.  

Share this post


Link to post
Share on other sites

 


First, never let a developer who has wrote a feature to write a test case for it. The test case must be written for someone else before the developer starts to work. If the developer tells someone what to test, then the tester is useless. The developer is biased and will never think of testing some stuffs (say, put a 10000 letters text inside a "Username" input field). It's not because he's a bad programmer or he's stupid, but the developer is trying to make something work and all his effort is into that.

 

This is not possible if  you have a really small team.  I worked for years where there were many projects and only 5 programmers.  Each person was completely responsible for multiple projects.  Most of the developers didn't have tests for anything.  The just hacked the code and prayed it would work. 

 

Also, test driven development is based on doing exactly the opposite of what you're describing.  

 

You're right, I forgot about TDD, but even in TDD you can forget some conditions, you code what's needed for you're tests to work, but you might miss some tests. And even then, you can't test everything with TDD, you can't do integration tests to see the whole flow of a user registering, receiving an e-mail, confirming with a link and loging in for the first time. The developer can do it, but there sould be someone else testing. I know it may not be possible in small teams, but OP was asking if a developer writes a test-case for QA impling that there's people available, maybe I shouldn't have write "never", but I thought it was clear what I was traying to say.

Share this post


Link to post
Share on other sites

Depending on the task type, there's a different "definition of done".

I've also found myself redefining that definition in some different project contexts (often tech-dependant).

 

A feature is generally done only when all necessary art is integrated (if that's relevant) and it has been QAed. Basically, it's done when the client/PO can see it, or when the user could use it.

But we also have intermediary steps of done, which we have a custom (visible) workflow for. It basically tells us who owns a specific task and what's left.

The plus to that approach is that the PM won't bug the programmer asking if it's done, when clearly, all programming has been implemented successfully.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • 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!