Jump to content

  • Log In with Google      Sign In   
  • Create Account


Member Since 08 Sep 2011
Offline Last Active Oct 10 2016 06:54 AM

Posts I've Made

In Topic: What is your definition of done?

17 April 2014 - 07:35 AM

Thanks for all the responses, It is interesting to hear different points of view. I guess it is not as easy as I thought to formulate a "done" definition.


i'm both dev and QA. its done when it s right, or as right as you can reasonably get it.


the "it's right" and  "reasonably" part is exactly what I would like to explore more here.


But back to your question, you really need to trust that your developers and testers know what they're doing. If they say its fixed, then they think it is. Of course there will be other problems and closed tasks will be reopened. That happens every day.


It is not about trust or about somebody not doing their job properly, but about that the view wheter something is fixed or not may differ depending on the view of the person. I just think that it might help to work together if all persons concerned share a common view when a piece of work is done. My experience is that there are sometimes some gaps between developers, QA and product managers when a feature is done and this can lead to some frustration on every side.


I see a lot of discussions like this which i think could be prevented by a definition when something is done:

PM: Is the login screen done?

Dev: Yes

PM: Cool, then we deploy it next week

Dev: Oh no, it's not back from QA and the definitive layout and images are still missing

PM: So it's not done?

Dev: No, it's done. I closed the ticket and handed it over to QA

QA: We're not testing without the layout and images, because else we're testing twice

Dev: So open a new ticket for the layout

PM: But the layout is part of the login screen, do why wasn't this added before QA


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

In Topic: What is your definition of done?

16 April 2014 - 02:46 AM

That's a vague question, but I can tell you how I've done it at various jobs in the past.


Either way, once the bug is fixed, or the feature is added, the job is marked as "done." It isn't actually "closed" until QA has tested the feature, and even then it can just be reopened if there is a problem.


I try to clarify a bit: I'm trying to get a feeling on how other teams handle it when they say "We're done with this feature" what prompts them to define that something is done? In your example you say you're "done" when you hand something off to QA. My guess is the QA has some requirements for accepting a feature to test; for example, they want the developer to describe a test-case before handing it off, or have some automatic unit-tests that need passing etc. For instance if your code doesn't build QA probably wont be able to test, so they hand it back because you are not "done"


And these rules are excatly what I try to get to. I'm wondering if other places have a checklist when stuff is ok to hand on to QA (or the end-user if QA is done by the devs)


I'm pondering about this because I was talking with a friend who is in QA and usually they have pretty clear rules when a feature is "done" in the term that it passes QA or not. But he was also a bit venting off on developers who deliver a "fix" without actually having run a program once or even telling what QA has to look at and then expecting them to handing out a "QA-Passed" label for it.

In Topic: How does one practice Scrum on himself/herself?

10 February 2014 - 06:19 AM

Practicing the "team" parts of scrum by yourself is almost impossible, as you are not able to reproduce the interpersonal relations of a team when you are alone. However the project-management parts are easily doable by keeping a high-level backlog, dividing it into stories and then into simple tasks, the way Tom wrote.


One of the key aspects of scrum is to have a "potentially shippable" product after each sprint, which is a very nice goal to train to. Have something working that you would be confident to display after a certain time greatly helps to get things done.


Also instead of practicing, get some reading done. I highly recommend "Scrum and XP from the trenches" (downloadable here: http://www.infoq.com/minibooks/scrum-xp-from-the-trenches ) for a practice-oriented read, if you already know the basics about scrum

In Topic: Alternative library to graphviz for layouting directed/undirected graphs?

04 February 2014 - 04:16 AM

So I finally found the Open Graph Drawing Framework (http://www.ogdf.net/doku.php) which does the job nicely.


It compiles out of the box and is easy to integrate in an existing project

In Topic: Web based game development WBS, cost and resource estimate

17 June 2013 - 01:37 AM

This is my first experience with game and web development industry so I don't have enough clue for Work Breakdown Structure and required resources.


Sorry if I sound harsh and disappointing, but considering the possible scope of your undertaking, I think you need to question if you are the right guy to do this job on your own, given your limited experience in two of the key fields of your project.

Now that that is said, if you already have a team of people with experience in these fields at hand, try to include them into your estimation. Do some collaborative requirements-engineering with your developers and customers, get your scope and vision together and only then you can give an rough estimate.