University of Dundee

Hard to believe that this is now week 9 of my penultimate semester/term at Dundee University, time has just flown in. While this is normally a good thing I am left realising that the available time to work on my honours project is deminishing rapidly. 

 

My honours project is focused around the management of software projects and teams across more than one methodology or management style. In-keeping with the theme of the project, I am working under an agile approach and will be utilising a number of aspects of Scrum (user stories, sprints, user-centred development, etc.) and because of this I am keen to enlist the support of the development community.

I am looking for open-minded people who will have a little bit of time going spare from January to April to play the part of the “customer” or “customers” in my project. My supervisors are keen to bring real people into the development and felt it would be a good to get some input from people involved in the software development process.

I am still in the planning stages of user involvement but I am aware of the need to start finding people willing to help out.

Ideally I am looking for managers a developers and designers in order to get a good spread of expertise and requirements although I am not expecting to get exactly what I am looking for.

More details of the project can be found on my Honours Project page.

Today saw the end of one of the largest pieces of on-going coursework we have done at university thus far. 6 people working together in a group for 6 weeks using a methodology that only 1 of them had any solid knowledge of at the beginning.  So, how did it go?

Putting aside the differences in experience and ability, pretty well. I find it hard at times to accept that I have an advantage over many of my peers in that I have more experience in development and methodologies. I read the articles and the books, I play with the tools and I learn very quickly.

It took time but the group really began to work closely together and especially in the 2nd sprint were able to work around tasks and keep things moving along. Communication became more free flowing and a bond formed that made working together much easier.

I think everyone has benefited from this project and has taken away something valuable from it. To get hands-on experience of both Agile and Waterfall approaches to software development before entering the industry is not something I would say is common and I think it has been a great opportunity for everyone.

I am not a fan of rigid designs and reports, they have their place but often they stifle productivity and creativity. Agile is growing and I am quite sure that at least once in their professional careers the other students will work in a team that uses an agile approach. By having this experience they will be more prepared for it.

I want to say well done to the team for this amazing effort, you all did well and hopefully you enjoyed it as much as I have.

I would like to say thank you to our Customer (although I doubt he will ever read this, doesn’t hurt to be courteous), Colin from Live and Lets Dive for presenting us with this challenge and for supporting the students.

And finally I would like to thank Janet for the hard work and effort she has put into this module in order to make this as enjoyable and as entertaining as it has been. Thanks Janet.

And so the end, well only of this project. The blog continues, university continues and my never diminishing quest for knowledge continues. If anyone outside of Dundee University has been reading this, I do hope it hasn’t bored you senseless or left you wondering “what on Earth?”.

Oh, and can I haz ur blocks?

Ahh, vast improvement on last sprint!

We met Janet (the Customer) and not only did we impress by asking if she would like coffee, we had refined our approach, presented what we had done and explained it clearly. Despite not having that much completed it actually look far more impressive than I thought it would.

As a team a lot of hours and work went into this second sprint and it was great to see that it had paid off and that most of the points that hurt us last time round had been resolved. We could have been more organised on what would be done in the theoretical third sprint but that really slipped our minds.

I am glad I threw in the little launcher application at the last possible minute, otherwise we would have needed a recompile mid demonstration, that would have been about as bad as showing raw XML or opening the sprint backlog spreadsheet (despite the fact I am quite proud of how I got that looking in the end, and thanks to Alan I learnt how you can restrict the values of a cell).

We did need to go back after the review and just tidy up a few loose ends for our coursework. Rory and Stacey made a really cool white box testing diagram, Alan and Paul finished up the black box testing and I sat and frantically collated all of our code, tests, backlog, etc.

I really enjoy the feeling of a team working together like that, even better against a deadline as it makes me work that bit harder.

So, as far as the review goes, amazing improvement and I really do hope everyone else feels the same.

Note to Janet:

This post and the one after it were written on Friday however I could not post them till Sunday evening.

I made a number of realisations today, let me list them:

1. We really needed to sit down as a group and think long and hard about how those dive tables were going to be stored and also how we can access them with a computer.

   Why?: Everyone who has looked at those tables has a different picture in their head of how they are being computerised, we don’t seem to have a single solid idea of how this is going to work. For example the table columns that Stacey and Alan used are partially inappropriate for actually accessing the data using a computer. I actually wrote code today that looks up a column, goes down to find a cell with the required data in it and then comes back up again to reference another cell just to get the residual nitrogen. That is very bad design and the time it takes to process is actually noticeable!

2. We underestimated the time that the computerisation of the tables would take.
3. Complex tasks often require more complex approaches (or simple approaches that use what can be considdeed “complex” implementation from those who are unfamiliar with them).

   This is more a failing with me than anything else. Presenting the group with the knowledge on how they can access the dive tables and use that seemed simple to me, evidently this isn’t the case.

The entire team really had to pull together today in order to get this block cleared out, all of the pairs plugging away at tasks and programming to try and move forward. The end result was code that could look up the tables and it managed to perform one of the calculations however doing much more really required a re-design of the table structure and so we could not implement it in the time we had.

I do feel we have better prepared for tomorrow however, we know what we did wrong last time (and I sure wont be turning up late nor looking like I have been run over by a hummer a couple of times). In essence better but could still be improved further. But then that is part of what we do in life, continually try and improve ourselves.

I knew it was coming, and it happened today. I ended up driving the refactoring of the computerised dive tables, we needed to get things back on track and so Paul took the navigator seat and I hammered out the code. In actual fact what Stacey and Alan had created was on the right track but embedded all of the tables inside of a class which was going to get very messy indeed.

I shifted out the tables into a comma separated file and fixed the interface to access it, Paul was quite interested to learn some of the techniques I use although I did get the feeling I lost him in places. Under normal circumstances I would have navigated and let him drive, teaching him the parts he was unsure of but the rest of the user story was held up waiting for this as it is and so this is how we solved it.

There is still more to do but it should provide a base to continue on from.

We also had a meeting with Janet (the Product Owner) in order to resolve a couple of minor discrepancies on our acceptance tests. These were to do with values we had used previously being off slightly.

Ah, the one thing Agile and Scrum seek to avoid has struck once more!

Yet again we have a coding task blocking us from moving forward, we thought we had avoided this problem by better defining our tasks however it would appear not. We cannot write code for calculating the residual nitrogen until we have an idea of how the tables are going to be represented and store. Perhaps this should have been designed better but then we have different levels of skill and ability in the group so that is one of those “Oh, we should have thought of that” type problems.

Anyway, while Alan and Stacey were working away on that Rory and I moved on to the third user story and actually managed to take care of a number of the tasks (design and GUI implementation). Was quite nice to see the chart start to go downward on the next story, gave a nice feeling of concurrency (or perhaps that is just John Arnott’s Computer Architecture lectures going to my head!).

The pair programming seems to be going more smoothly this time around, all three teams working hard on their tasks, was a very nice atmosphere.

A couple of quotes from today that made us all smile (after seeing a comic strip about the upcoming Lego online game):

“Learn to build n00b”

“Can I haz ur bricks?”

The Refactor Tractor has been beaten….by Lego!

Technically an off day for the agile project however Paul and Martyn researched the residual nitrogen calculations and came to a rather disturbing truth that all of the data from the PADI tables is going to have to be computerised.

While the research was going on there were some more problems with the source control however most of it is due to the team having to pick up an entirely new concept, let alone a new system. All seems to have smoothed out however, just got to keep reminding people of the steps the need to take in order to check files in and out.

Scrum master for the week is Stacey.

As I pointed out yesterday we had a large HCI hand-in today and really the entire team needed to focus on collating all of our material together into the report.

To start our day off there were numerous problems with the source control and continuous integration server, documents were not checking out properly etc. But after a little bit of jiggling everything sorted itself out. As I have said before, it would have been great to have had source control right from the start but due to the nature of the module and the learning curve being so steep to begin with, there is just no way you could have students trying to understand everything at once.

On the subject of source control, I really have started to dislike Team Foundation Server. Huge, bloated over-powered behemoth of a system that when you only need a fraction of it’s features actually wastes more time than it saves. Doesn’t meant I won’t ever use it and it has been useful to get some hands on experience using another type of source control but it most definitely wont be my first choice.

Subversion is lightweight, portable and entirely cross-platform. It doesn’t need a huge hulking backend server or advanced configuration, all you need is a web server, the pre-compiled SVN modules and the Subversion command line client. There is even a free deployable server for windows that you can install and have a working SVN repository in minutes (Check out VisualSVN Server). There are GUI’s for Windows, Mac OSX and Linux and there are even plug-ins for many of the major IDEs (Visual Studio, Eclipse, NetBeans, etc.)

Why do I love Subversion (apart from the above)? It’s simplicity! You can make your repository as simple or as complicated as your project demands and changes can be made easily. I carry around the svn client on a pen drive and I keep the majority of my projects (university, business and personal) stored in online SVN repositories I can access from almost any computer with an internet connection.

Anyway, I just needed to get that off my chest

As for the meeting with Janet today, not much to say on that, another paper to look at and report back on, we just have to get the finger out next week on the agile.

With another major hand-in tomorrow (HCI) we didn’t actually get much done today beyond a short scrum meeting. This is something that has really begun to bother me this semester and there is no real solution to it. We have so much coursework that overlaps despite having spaced out hand-in deadlines that it gets very hard to balance them all.

Group work is a very hard thing to manage on it’s own, however when you have multiple projects all vying for attention it makes the tasks even harder. I would like nothing more to devote 6 whole weeks to nothing but Agile however we have no such luxury in university. A shame, but such is life.

I wasn’t in today simply because I put off a meeting with a business contact for 3 weeks in order to do group work and yes I know I am supposed to be in University for group work and such, however we have 2 labs on a Wednesday and no lectures, during the labs we all work on group work anyway and I was not about to let my client down 4 weeks on the trot, not when there is business at stake.

As far as the project goes, well I managed to put everything into source control this evening, just got to hope everyone knows how it all works and doesn’t give the team hassle with Check Out/In locks (which are so much fun when the person who locked the code has gone home for the night).

Team seems to be getting on okay and to a point I am trying to take a little bit of a back seat from the programming tasks.