Category: Project Management

Quality assurance ideas in agile developement

~ Gonzalo Ayuso ~ 2 Comments
Nowadays being agile is cool. All people is speaking about Scrum and agile development. There’s even people going far away and speak about Kanban. Agile development isn’t a new idea. Maybe it’s only setting up a name to an old one.Quality assurance activities should be designed to identify missing, ineffective or inefficient policies, processes and procedures used in the project. According to the PMBOK guide there’s a tool to perform quality audits called root analysis. Basically root analysis aims to find the source and the solution of the problem and helps to determine inefficiencies. Performed it regularly you can fine tune processes. The steps to perform root analysis technique: 

  • Define the problem
  • Gather data to describe the problem
  • Determine possible causes
  • Select the root cause
  • Develop a solution strategy
  • Test and evaluate the solution

Clients must bear in mind agile development means they must take actively part within the development process. Maybe some clients don’t like this way of work. Maybe they prefer to pay for the service or deliverable and let the work for us. But really it worth the effort. Work close to the client is one of the principles of agile development. One important action to obtain the commitment between both parts is give access to the customer to the Bug Tracker. With this simple step our customer can track our work. But there’s a problem. Our bug tracker is not only an internal development tool now. It has become also into a communication tool. That’s means developers maybe decide don’t report internal technical things because they don’t want to be read by the clients.

Bug trackers can help us in our agile developement. There’s a lot of bug tracking software over there. Open source software you can install in your host, such as Mantis or Track. You can find also hosted solutions, free or paid ones. Probably Jira is the most famous and widely used software(not a free software).

Currently I’m thinking about the bug life cycle. I’m trying to standardize the way we use to face the bugs. I’ve created the following flowchart:

 

What do you think about this flow chart? Do You think is it is up to your requirements?

Digressing about working with old code, refactoring and scope creep.

~ Gonzalo Ayuso ~ Leave a comment
Maybe there’re people who write code without bugs and never need to change one line of their source code. That’s not me. I try to improve my coding skill for the years. That means sometimes I need to face against my old code and if need to rewrite it probably I will do in a different way. I always feel the desire to refactor it. Refactor code is a good thing but is not always viable.Let’s show an example. Nowadays I’ve embraced Zend coding standard. For instance one not camelized variable creeps me out. But in my early days as a PHP developer (almost ten years ago) I didn’t take care about any coding standards. If code worked, it was OK. Now I realized that’s not enough. Code must work. Indeed!. But it must be ready to be changed, adapted to new needs and meet new requirements, and another developer must be able to understand it. Last days before holidays I’ve been working adapting a project to PHP5.3. It’s not a hard job. Some functions have disappeared, now we only have one kind of regular expressions and a couple of things more. I need to check a lot of lines of code. Sometimes I blush myself when I see the code I wrote five or even eight years ago. I want to change a lot of things. Refactor again and again but I must remember that’s not in the scope of the project. The objective of the project is clear: The application must work in a server with PHP5.3. If I start to refactor code the project deviates from project’s main scope. That’s a clear scope creep’s signal.

According with theory the main signals of scope creep are:

  • More work has been done than required
  • Product features don’t match the specifications.

Scope creep one of the most important problems in real projects. It’s very difficult to explain to someone that you will delay your project because you have decided to refactor some pieces of code (code that worked). That’s means your project will be delayed because you’ve decided to improve something that nobody ask for it. If you are on schedule maybe you can assume some refactor but think this kind of work is only viable if the triple constraint model (aka Scope + Budget + Schedule) keep unaltered. You must assess if those unsolicited changes have any impact in the project. Projects must end at some point. At some point you will need to submit the project’s deliverables, put your feet up and relax. But the temptation is big. I know.