This is an assessed reflection on some workshops that we did for Agile Methodologies
As part of the course we have done three two hour workshops on Agile methodologies. These have been interesting as they have formalised the practises that I had been doing previously in my industrial year.
For example I wasn't aware that pair programming, test driven development, and continuous integration were part of extreme programming, however I had been using them all year. It was also interesting to see that other practices I had been trained in were closely related to the agile manifesto, such as creating and weighting stories, but we weren't following agile in any formal way.
Pair programming is an excellent tool and from experience of the workshops, personal projects and my industrial year, I can argue that working as a pair is a lot more efficient than working individually. The caveat for this is that both partners are at the same level of familiarisation with the code base. On numerous occasions in my industrial year a colleague would work with me to solve an issue, but because they knew the systems a lot more intimately it would have been a lot more time efficient for them to have performed the work themselves.
Prior to the workshop on pair programming myself and my partner had been practicing the night before. During this practice we didn't have a driver and a navigator, but rather discussed what we would do, and then the person with the keyboard would implement it with the other checking.
This seemed quite different to what we experienced in the workshop where we were encouraged to have the driver write what they wanted and then the navigator comment on it. The other difference was that we were encouraged to swap over roles frequently. This didn't seem to work as the process of swapping roles broke our workflow, and hurt efficiency simply because one of the programmers is not as familiar with the setup of the system / IDE as the other. Perhaps it would work well if the machine that was being used was identical to the ones that the developers normally use, however I can't really see that ever being the case, as programmers all like their systems setup differently.
I would like to retry the workshop with a focus on discussing the problems between the pairing, and not worrying about who is actually writing the code. I think this would lead to better results as it becomes more of a discussion than programming with interruptions.
I really like TDD, I find it an excellent way to maintain focus on what you need to be doing at that moment in time and not worrying about the bigger picture of the application.
The flow of work that I have followed has been slightly different to red-green-refactor, in that I usually write the tests, have them fail, then make the functions being tested return what is required for them to pass. Once I know that my tests are written correctly (as the tests now pass) I will then implement the function to get to the correct return value. This method would be more like Red (Write the tests), Green (Flesh out skeleton functions that return the correct result), Implement (Have the functions calculate the correct result).
I then tend to use the tests as a guard against regressions which is invaluable in refactoring.
CRC cards seemed a little pointless to me. It was halfway between creating a fully fledged UML class diagram and initial sketches on a whiteboard. From my experience I find it a lot easier to discuss a problem with others and use a whiteboard to get a general overview of how the application would be structured and then create the UML diagram based off of that. Although in practice (and in industry!) I would skip the UML step and start creating skeleton tests and classes based off of the whiteboard design.
After a year in industry and discussing with my colleagues and other industrial year placements, it seems clear to me that UML really isn't used in the planning stages, the only time I've heard of it being used is when it is retrospectively generated from the codebase to create a diagram.
I definitely think so, the nature of software projects lends itself to the need to be flexible. Very often there are times where either a requirement changes or an oversight in the implementation requires a large change to the code base. Using agile to develop allows for this to be less of an issue as you aren't tied down to a specific stage of the development.
Test driven development is probably the most important part of agile, as it encourages the writing of tests which makes the development and maintenance of a project so much easier, as any future regressions can be seen before code is deployed. In addition if there are bugs found in edge cases or untested areas of the code, writing a test when the bug is fixed will ensure that it doesn't happen again and will reveal what edge cases you should be writing tests for in the future.