One of my favourite modules at University was Human Computer Interaction 1 & 2. It was taught very well by Dr. Russel Beale and was fun and interesting. I learnt a lot from that module especially in terms of the human aspect of designing a system and web sites.
However, one thing I have found is that in the business I work in, HCI tends to be put on the back burner. It's usually not seen to be as important as the core functionality of the system and seen as 'cosmetic'.
I find it quite frustrating that basic concepts such as good colour schemes, affordances and metaphors are not taken into consideration when designing systems. Usually decisions for look and feel are made by the client, but there tends not to be a usability expert on either side to say 'hold on a second, we shouldn't do it like this because that page will look noisy' or 'the buttons shouldn't be arranged as 'Cancel' 'OK' as when people hit enter on most systems they are expecting it to click 'OK' and not 'Cancel'.
Other things we tend to lack is that (apart from UAT) we don't have end users directly involved with using the system iteratively as it is progressing. Techniques like Cognitive Walkthroughs would provide us with a fantastic insight into how we can make systems more user friendly.
Usability studies are usually based around human psychology and human perception and if the system layout doesn't meet the user's expectation then they will be reluctant to use it or they will not use the functionality to it's fullest.
Finally, I know the IT and business world isn't as black and white as this and text book answers cannot always be used due to other constraints. My goal is to try and incoporate HCI and Usability practices wherever possible.
Some Links to Usability Sites:
Neilsen's Usability Heuristics
Usability First
Friday 20 February 2009
Automated UI Testing using Ruby and Watir
Just before Christmas our Scrum Master was asked to come up with a way of automating UI testing using open source software. He came across Watir (Web Automated Testing in Ruby).
Creating scripts in Watir is very easy to do. Our Scrum master (using the watir API) has written some classes including domain specific ones (relating to our project) thus making it very easy for anyone to be able to write scripts.
The point of this was to help with regression testing so that it is almost push a button and the scripts will do all the work for UI testing. Obviously there are limitations (such as automating email activation) but it is devised in such a way that writing a script has a natural language feel to it.
We have been incorporating the writing of these scripts as screens are developed in our sprints, this allows us to provide better test coverage.
The scripts have mostly been written by the developers and a tester, we were hoping that the testers would be more enthusiastic in getting involved, however this has not been the case. I think they are a bit hesitant and would rather go through every single screen than to trust the automated process, which is a shame really as it works so well.
For further details on the technical aspect of Watir, please visit the link provided.
Creating scripts in Watir is very easy to do. Our Scrum master (using the watir API) has written some classes including domain specific ones (relating to our project) thus making it very easy for anyone to be able to write scripts.
The point of this was to help with regression testing so that it is almost push a button and the scripts will do all the work for UI testing. Obviously there are limitations (such as automating email activation) but it is devised in such a way that writing a script has a natural language feel to it.
We have been incorporating the writing of these scripts as screens are developed in our sprints, this allows us to provide better test coverage.
The scripts have mostly been written by the developers and a tester, we were hoping that the testers would be more enthusiastic in getting involved, however this has not been the case. I think they are a bit hesitant and would rather go through every single screen than to trust the automated process, which is a shame really as it works so well.
For further details on the technical aspect of Watir, please visit the link provided.
Demo & Retrospective
Demo
Even though it was a late night on Wednesday, we managed to get all our stories 'done' ready for the demo the next day. I was told by the scrum masters that the demo with the client went very well. The only disappointing thing is that apart from the Scrum masters and the BAs and other management types outside of the sprint teams.
I raised this during the last retrospective and an item was actioned for this. However, nothing came about of this. The scrum masters decided that the team members should go to the dry run prior to the sprint demo. I was one of those who went along, it was nice to see our work up there and as one of the client is a part of our sprint team, it was re-assuring to see him presenting and selling the end product so well.
The only issue is that the sprint teams should have the option of going to a client demo whether they choose to or not is up to them. Ultimately it is the sprint team who have produced the work and the client should have exposure to this, it feels a bit like they're being shielded from the sprint team. I know that management have their reasons and that 'rooms are too small' etc, even if the sprint team were there as observers it would be a good learning experience for the team too, especially those that have not been involved in agile development before.
Lastly, it is one of the practices of Agile, that team members should be present at demos! I mean after all, we only did the work!!!
Retrospective
So we had our 2 hour retrospective meeting (which went over the 2 hours) and a lot of discussion came about.
The approach that was taken was that prior to the meeting our team (on flipchart paper) wrote down the positive and negative elements of the sprint.
In the meeting we created an agenda which was:
1) What went well
2) Could do better
3) Like to start doing
4)Actions
5) AOB
We went through the flipchart list, discussed them and then came up with an action list.
What has happened in the past is that action has not been taken on the action list (see what I did there). That was another point that was raised, so let's hope this time round that something comes of the actions.
Even though it was a late night on Wednesday, we managed to get all our stories 'done' ready for the demo the next day. I was told by the scrum masters that the demo with the client went very well. The only disappointing thing is that apart from the Scrum masters and the BAs and other management types outside of the sprint teams.
I raised this during the last retrospective and an item was actioned for this. However, nothing came about of this. The scrum masters decided that the team members should go to the dry run prior to the sprint demo. I was one of those who went along, it was nice to see our work up there and as one of the client is a part of our sprint team, it was re-assuring to see him presenting and selling the end product so well.
The only issue is that the sprint teams should have the option of going to a client demo whether they choose to or not is up to them. Ultimately it is the sprint team who have produced the work and the client should have exposure to this, it feels a bit like they're being shielded from the sprint team. I know that management have their reasons and that 'rooms are too small' etc, even if the sprint team were there as observers it would be a good learning experience for the team too, especially those that have not been involved in agile development before.
Lastly, it is one of the practices of Agile, that team members should be present at demos! I mean after all, we only did the work!!!
Retrospective
So we had our 2 hour retrospective meeting (which went over the 2 hours) and a lot of discussion came about.
The approach that was taken was that prior to the meeting our team (on flipchart paper) wrote down the positive and negative elements of the sprint.
In the meeting we created an agenda which was:
1) What went well
2) Could do better
3) Like to start doing
4)Actions
5) AOB
We went through the flipchart list, discussed them and then came up with an action list.
What has happened in the past is that action has not been taken on the action list (see what I did there). That was another point that was raised, so let's hope this time round that something comes of the actions.
Thursday 19 February 2009
This is what happens when the system goes down...
...between 5.30-8.30 pm on a Wednesday night (the day before the demo and one last script to System Test).
(Artists: Femz & Wadz)
(Artists: Femz & Wadz)
Tuesday 17 February 2009
Multi-Functional Teams
As mentioned in one of my previous posts, sprint teams are meant to consist of team members who are multi functional. Although, we tend to have defined roles (i.e I'm a developer and person x is a tester, person y a business analyst etc) the whole multi-functional teams has been put to the test this week.
In the past BAs have taken on testing roles especially towards the end of a sprint, however this time round we've managed to finish all the development and the bottle neck is at the testing end. So myself, and the rest of the developers have put on our testing hats and started testing (obviously not code that we have written and the test conditions have been written by the testers).
It's not so bad as long as the test conditions are written well and it's a case of executing them and raising any defects. At the end of the day, the ultimate goal is to get the stories into 'done' and points on the board, so it's much more beneficial to help out in this way then to sit there twiddling our thumbs.
In the past BAs have taken on testing roles especially towards the end of a sprint, however this time round we've managed to finish all the development and the bottle neck is at the testing end. So myself, and the rest of the developers have put on our testing hats and started testing (obviously not code that we have written and the test conditions have been written by the testers).
It's not so bad as long as the test conditions are written well and it's a case of executing them and raising any defects. At the end of the day, the ultimate goal is to get the stories into 'done' and points on the board, so it's much more beneficial to help out in this way then to sit there twiddling our thumbs.
Running a Stand Up Meeting
So yesterday, I was given the opportunity to run a stand up meeting which was pretty cool. I jokingly suggested it to the scrum master that if he 'wanted me to run it' and he agreed.
It was an interesting experience, a little bit daunting being up there however the fact that it was an informal environment and we have done many stand ups in the past few weeks meant it wasn't as bad as I thought it would be.
Being up there put me out of my comfort zone which was a good learning experience. I think it's a good idea to rotate around the team to run the stand up meetings.
It was an interesting experience, a little bit daunting being up there however the fact that it was an informal environment and we have done many stand ups in the past few weeks meant it wasn't as bad as I thought it would be.
Being up there put me out of my comfort zone which was a good learning experience. I think it's a good idea to rotate around the team to run the stand up meetings.
Tuesday 10 February 2009
Stand Up Meetings
During our stand up meetings we have been 'mixing it up' a little. Initially it started out with going round the team members and each one stating what they have been working on yesterday, what they are working on today and providing estimates of tasks allocated to them.
Lately we have started doing our stand up meetings based upon the story, so we go through each story and discuss the progress. I find this a far more effective stand up as a) everyone should be working on a task and therefore everyone gets a chance to speak b) the progress of each story is much more obvious c) there is less digression during the meeting and d) it re-aligns focus.
I think the latter process works very well, that's not to discard the former though as there are times when the former is more effective (especially at the beginning of a sprint).
Lately we have started doing our stand up meetings based upon the story, so we go through each story and discuss the progress. I find this a far more effective stand up as a) everyone should be working on a task and therefore everyone gets a chance to speak b) the progress of each story is much more obvious c) there is less digression during the meeting and d) it re-aligns focus.
I think the latter process works very well, that's not to discard the former though as there are times when the former is more effective (especially at the beginning of a sprint).
Sunday 8 February 2009
Agile Methodology
The first time I heard about the Agile Methodology was when I was working on my previous project. We were using RUP, however being a large scale project things weren't quite going according to plan.
A few of our senior software engineers got together and decided to take the Agile approach. It worked very well for us and we pulled ourselves out of the rut and delivered on time, which the client were very happy about.
The basic gist of Agile is collaborative working. The following exist in Agile development:
Generally there is a business problem that needs to be solved through the development of software and the person responsible for this problem is the product owner, who has a product backlog of business problems.
A team or multiple teams known as sprint teams are formed for this purpose. They generally consist of developers, testers, business analysts and a scrum master. Sometimes (but not commonly the product owner or the product owner proxy). The team is a self organising, multi tasking team. The team will work on the software in sprints. A sprint is a fixed amount of time (between 2-6 weeks).
At the beginning of each sprint the team is involved in a planning session where they determine the velocity that they will work at. During the planning session, the team take the backlog and prioritise what needs to go into that sprint. They then divide these up into stories and assign points based upon the velocity. The points are assigned using planning poker, and team members have to estimate individually, then once every team member has indicated their estimate a consensus is reached based upon discussion.
After the planning session the team work on the tasks (these are the stories broken down into smaller components) in the sprint and every day a 15 minute daily meeting occurs where they discuss their progress amongst other team members.
There is no outside interference when a sprint team is working. At the end of the sprint there is generally a demo to demonstrate what was achieved and a retrospective meeting held for lessons learnt.
This is the basic gist of Agile development. For details please visit the link above or read Scrum and XP from the Trenches.
On my previous project I worked alongside a sprint team, mostly working on support work for the teams so I wasn't really involved in the core development for the sprint team.
When I joined my current project, we were encountering similar problems to those of my last project. There were a few of us from our previous project who joined the current project. Once again a couple of the senior guys suggested Agile development.
Once again this worked very well and we were able to deliver Release 1. For Release 1 our business analysts were the product owners. Once again, I wasn't involved in the core development within a sprint team.
My first real experience with Agile development was about a month ago when we started Release 2. I had expressed an interest in being involved with core development work and was finally provided with this opportunity.
This time round the product owner was the client, and their proxies are actually a apart of our sprint teams. I hadn't really been to a planning session before and it was a very interesting experience. During my first planning session, I found it very hard to determine how to allocate points to the stories as I'd never worked on a story (or core development before). We had time boxed the planning session to 3 hours, however it overran due to lengthy discussion about the stories.
We started the sprint and I must say, I found Scrum to be a very effective way of working. The teams work very closely together and having all the developers, testers, business analysts and the client(as the proxy) together meant that the team was very productive. I found that having stories and allocated time for tasks meant that I focussed much more on achieving my goal. Also with everyone sitting together the communication and turn around was excellent.
Including a client member on the team also means that we get a much quicker response back from the business and that they are more sold into the process and ensuring the success of the team as they are also liable.
The retrospective was very interesting also, we were given sheets of paper to write issues we encountered during the sprint and how we could resolve them for the next sprint. The scrum masters then went through the common themes and discussed them. Recurring themes were given higher priorities to over come for the next sprint. Basically, everyone got to have a say.
Our second (and final) sprint for this release started on Monday. I was better equipped for the planning session and able to make sound judgements on point allocations. So far the week has gone well and we seem to be on track.
I will keep posting our progress as the weeks progress :)
A few of our senior software engineers got together and decided to take the Agile approach. It worked very well for us and we pulled ourselves out of the rut and delivered on time, which the client were very happy about.
The basic gist of Agile is collaborative working. The following exist in Agile development:
- Product Owner
- Product backlog
- Sprint team
- Backlog
- Stories
- Points
- Tasks
- Burn down chart
- Velocity
- Planning Session
- Stand up meetings
- Retrospective
Generally there is a business problem that needs to be solved through the development of software and the person responsible for this problem is the product owner, who has a product backlog of business problems.
A team or multiple teams known as sprint teams are formed for this purpose. They generally consist of developers, testers, business analysts and a scrum master. Sometimes (but not commonly the product owner or the product owner proxy). The team is a self organising, multi tasking team. The team will work on the software in sprints. A sprint is a fixed amount of time (between 2-6 weeks).
At the beginning of each sprint the team is involved in a planning session where they determine the velocity that they will work at. During the planning session, the team take the backlog and prioritise what needs to go into that sprint. They then divide these up into stories and assign points based upon the velocity. The points are assigned using planning poker, and team members have to estimate individually, then once every team member has indicated their estimate a consensus is reached based upon discussion.
After the planning session the team work on the tasks (these are the stories broken down into smaller components) in the sprint and every day a 15 minute daily meeting occurs where they discuss their progress amongst other team members.
There is no outside interference when a sprint team is working. At the end of the sprint there is generally a demo to demonstrate what was achieved and a retrospective meeting held for lessons learnt.
This is the basic gist of Agile development. For details please visit the link above or read Scrum and XP from the Trenches.
On my previous project I worked alongside a sprint team, mostly working on support work for the teams so I wasn't really involved in the core development for the sprint team.
When I joined my current project, we were encountering similar problems to those of my last project. There were a few of us from our previous project who joined the current project. Once again a couple of the senior guys suggested Agile development.
Once again this worked very well and we were able to deliver Release 1. For Release 1 our business analysts were the product owners. Once again, I wasn't involved in the core development within a sprint team.
My first real experience with Agile development was about a month ago when we started Release 2. I had expressed an interest in being involved with core development work and was finally provided with this opportunity.
This time round the product owner was the client, and their proxies are actually a apart of our sprint teams. I hadn't really been to a planning session before and it was a very interesting experience. During my first planning session, I found it very hard to determine how to allocate points to the stories as I'd never worked on a story (or core development before). We had time boxed the planning session to 3 hours, however it overran due to lengthy discussion about the stories.
We started the sprint and I must say, I found Scrum to be a very effective way of working. The teams work very closely together and having all the developers, testers, business analysts and the client(as the proxy) together meant that the team was very productive. I found that having stories and allocated time for tasks meant that I focussed much more on achieving my goal. Also with everyone sitting together the communication and turn around was excellent.
Including a client member on the team also means that we get a much quicker response back from the business and that they are more sold into the process and ensuring the success of the team as they are also liable.
The retrospective was very interesting also, we were given sheets of paper to write issues we encountered during the sprint and how we could resolve them for the next sprint. The scrum masters then went through the common themes and discussed them. Recurring themes were given higher priorities to over come for the next sprint. Basically, everyone got to have a say.
Our second (and final) sprint for this release started on Monday. I was better equipped for the planning session and able to make sound judgements on point allocations. So far the week has gone well and we seem to be on track.
I will keep posting our progress as the weeks progress :)
Software Engineering in Industry
As an AI student at University I didn't really focus much on the software engineering part of Computer Science. We mostly worked on AI and intelligent algorithms and principles. A lot of the Computer Science students and especially the Software Engineering students were taught the different methodologies and principles. The only software engineering I had done was a module in my first year and writing my dissertation in a software engineering fashion (can be found on my website).
So when I started working it took a while to get into Software Engineering practices, especially on large scale projects. At present our company adopts IBM's Rational Unified Process (RUP) on software development projects. This has worked well, however recently we have started using Agile (will be discussed in my next post) alongside RUP and it seems to be working very well.
So when I started working it took a while to get into Software Engineering practices, especially on large scale projects. At present our company adopts IBM's Rational Unified Process (RUP) on software development projects. This has worked well, however recently we have started using Agile (will be discussed in my next post) alongside RUP and it seems to be working very well.
First Post
The first post of a new blog is always a bit difficult. I have so many blogs dotted all over the place from uni days etc, now that I'm all grown up and working I thought I would create a more grown up and technical specific blog.
I work for an IT consultancy company (I started as a graduate on the grad scheme) and about 3 months ago moved into a business unit focussing on development, therefore I thought it would be a good idea to keep a technical blog on technical/methodology related stuff and my experiences. So that's it really, I hope you enjoy reading my thoughts and feel free to comment.
I work for an IT consultancy company (I started as a graduate on the grad scheme) and about 3 months ago moved into a business unit focussing on development, therefore I thought it would be a good idea to keep a technical blog on technical/methodology related stuff and my experiences. So that's it really, I hope you enjoy reading my thoughts and feel free to comment.
Subscribe to:
Posts (Atom)