Sprint 2 – Day 1, Tuesday

 AC31002, Projects, University  No Responses »
Feb 192008
 

Yesterday was a long day, I had been up late working on a database assignment and had been on my feet since 7am working on more coursework including a trip to Dundee College to give a presentation for HCI and gather feedback. I was shattered by the time we were done so I decided just to come home. I knew that Agile was really on hold till today anyway since Monday is our “Sprint Planning” day despite doing that on Friday however we were yet to select the tasks as navigators.

The only thing that really took place (from what I have been told) was to organise our Sprint Backlog in excel and that was it. Two new tasks were added to the backlog however only one made it into the sprint and it was only really patching a problem with the first user story from sprint 1.

Scrum master for the week is Alan.

Paul and Alan worked on redesigning the view for the first user story and got on well, 2 out of the 3 tasks are now green. Great start!

Stacey and Rory made a start on the 2nd user story and I took a little bit of time to write up a Coding Standards document, nothing too long but something I hope will cut down on refactoring:

CODING STANDARDS

I advice the following standards be used on all source code developed on this project. They help increase the ability for other members of the team to read code and reduce the number of mistakes.

1 NAMESPACES

1.1 Namespaces should be of the format: DivePlanner.<project>.<folder>


Examples:
DivePlanner.UI
DivePlanner.UI.Controls
DivePlanner.Data.Validation

Be aware that creating a new folder inside a project in Visual Studio automatically tags the name of the folder on the end of any code files that are placed inside of it.
1.2 If you find that a collection of classes all perform a similar type of function (such as Validation), place them in their own folder and give them their own interface.

2 CLASSES & INTERFACES

2.1 Use CamelCase for class and interface names, that means the first letter of each word is a capital, eg. DivePlanner or IPlanner.
2.2 Exception: Uppercase abbreviations in class and interface names, such as IO, XML, etc.
2.3 Prefix interface names with I (capitol i).
2.4 Use meaningful and descriptive names for classes, for example DivePlannerIO implies that it performs IO handling for the DivePlanner.
2.5 Only put one class in a file
2.6 Exception: Structs, enumerations and internal classes are exempt from this rule. Place structs and enumerations at the top of the class file. Place internal classes at the top of the parent class definition.

3 COMMENTS

3.1 Avoid using inline comments to explain the function of a few lines of code
3.2 Use XML comments to describe classes, interfaces, structures , properties and methods

More information:
http://msdn.microsoft.com/msdnmag/issues/02/06/XMLC/ http://blogs.msdn.com/ansonh/archive/2006/09/11/750056.aspx

Posted by Andy Gibson at 20:58  

Friday – Sprint Review for Sprint 1

 AC31002, Projects, University  No Responses »
Feb 152008
 

Finish the sprint by starting the day with a screw up. Yes, I was late!

My alarm refused to go off and I slept in till 9.30, threw myself out the door and got to the meeting 5 minutes late, so first bad mark there. To make this even worse I didn’t realise this was being role-played and so while trying to prepare to answer a question (I wanted to sneak a look at the sprint backlog) I caused a second screwup for which I appologised to the group for. I was mortified when I realised what was actually going on, that this wasn’t a meeting with Janet the lecturer, it was a meeting with Janet and Craig the “Customer”. Whoops.

So, disaster aside we managed to re-order the product backlog for the customer in such a way that I think they were happy. One of the stories that would have made the backlog for the second sprint had most of it’s requirements already completed so we reduced the complexity based on that information. The customer replied by reducing the business value and adding a new user story.

After the changes to the backlog were complete in which we walked away happy we proceed to have an informal meeting to discuss sprint 1 and what we thought of it. We know we didn’t do amazingly well, we also know that there are things we need to improve for the next sprint.

On the flip side we all did agree that we have definitely all learned something from this sprint and we do feel that the next sprint will be easier since we have a better idea of TDD, Pair Programming and Scrum. We also know what mistakes we made and what to avoid, which is part of the whole process.

We did then move on to have our Sprint Planning Meeting for sprint 2 and we identified that the user stories will be easier this time around and we took a lot more time thinking about the tasks, breaking them down, discussing them and assigning real estimates of the times they will take. This is something that really hurt us in the first sprint and none of us wanted to make that mistake again. We totaled up the number of hours we assigned each task, broke it down in to the pairs and looked at the complexity we had assigned each story, judging by this we have got much better estimations this time round.

We may even managed to blow right through the backlog and get onto another user story, that would be a nice bonus to this. It would be in stark contrast to sprint 1 where we only got 1 out 3 stories completed.

On the whole I do feel we could have done better on the first sprint but there are a number of reasons why we didn’t and a lot of this has been to do with the learning curve involved. As stated in one of the scrum case studies, most sprints are 4 weeks long and it takes teams usually 2 or 3 sprints to actually “gel” together and work together in the best way possible. We do not have that luxury and 2 weeks per sprint really forces some hard and fast decisions to be made, especially when this is not the only project of this scale on the go.

In the end, we can only do so much and the team has really put in the effort for this, we are all ready for the second sprint and hopefully it will go much better.

And just because it was the highlight of my day today:

“Everyone on the Refactor Tractor!!!” (ask Alan, he started it!)

Posted by Andy Gibson at 15:37  

Sprint 1 – Day 7 Thursday

 AC31002, Projects, University  No Responses »
Feb 142008
 

I have been on a really good high note today. A combination of feeling really confident and happy with my interview with NCR and the fact that the team is pulling together to see this sprint to the end with at least one completed story.

The last task was really to connect our UI to our backend and test it but after hours of riggourous coding and testing yesterday we know our backend is fairly solid so things went fairly smoothly.

There was a bit of refactoring on UI stuff and we added documentation to the form and the user control. Hopefully the refactoring we have done should be easily noticeable.

First sprint is almost over.

Posted by Andy Gibson at 21:06  

Sprint 1 – Day 6, Wednesday

 AC31002, Projects, University  No Responses »
Feb 132008
 

Long day. Due to the problems yesterday I switched in with Stacey to help with some of the code and to try and keep the project on track. Today was the first day that we were all working on Agile all at once and it was quite nice to get the dynamic moving.

It does help when there are no lectures and other associated interruptions that we usually have in our day. I swapped in out on both the saving to XML and the validation code and it was quite enjoyable to help the others. I do find it hard at time when I know that I work to a higher standard of code because I keep reading and keep ahead of the game and it is unfair to expect that of my peers, but it is a good preparation for working in teams.

We may just pull this user story off yet.

Posted by Andy Gibson at 22:02  

Sprint 1 – Day 5, Tuesday

 AC31002, Projects, University  No Responses »
Feb 122008
 

We have hit a snag in the development process, due to not really thinking our tasks through properly we are having to wait for one task to be completed before we continue. Now this should not happen as such, there should be enough tasks for people to work on to avoid this kind of situation.

Paul and Stacey were working on the saving to XML but stalled at the first hurdle of unit testing in nUnit. They spent over an hour trying to get a single test running and in the end it turned out to be not declaring the test class as ‘public’. While this is an easy mistake it did hold the entire project up and they did both agree that if one of them swapped out and worked with another group member who was confident in their knowledge of nUnit they would have gotten on better.

Still, the idea behind this is to learn and they both did.

If nothing else, the rest of us did make good progress on the HCI project.

Posted by Andy Gibson at 19:51  
 Older Entries  Newer Entries
© 2011 Andy Gibson
Header image courtesy of Don Solo		 Suffusion theme by Sayontan Sinha