Scrum Master: Alice Hodkin

UML:  Ben Adlington

Paired Programming: Michael Hancock , Charles Hackett

Test Cases: Prince Ofori, Barnaby Smith

Sprint Aims:

• Come up with additional test cases if necessary
• Complete use case diagram and start domain model
• Program the back end so that the socket can connect to the server
• Program the back end so that the code and the GUI can be tested

 

Testing – Barnaby Smith, Prince Ofori

These are the test cases for sprint for sprint 2. They are all black box for test driven development. They may need altering at a later date due to any possible changes that may occur.

Prince Ofori: Expanded

This sprint the role of tester was assigned to me by the scrum master, the primary task I and Barnaby were set was to define functional test cases that would inform the design of the application. Due to the nature of SCRUM the testing team of which I was part began writing the test cases whilst the development team were writing the code. This synchronicity is unusual in iterative development methodologies, SCRUM however allows the implementation of test driven development (TDD). The process of developing these test cases was not exceptionally time consuming and they were passed along to the development team to review their code whilst in the process of development allowing developers to develop code that passes the test and can be easily in future SPRINTS or releases.

The role of TDD in the development of the application cannot be understated. The short development cycle (1 week long SPRINTs) resulted in varying sub-teams within the group working at the same time, communicating between groups to inform and improve the development of the application was key to the increased productivity of this sprint as compared to the first sprint.

Barnaby Smith: Expanded

Ben Adlington – UML

Above is the UML that I have created for sprint 2. It contains a basic design for each of the classes for the application that we will be creating. These designs may need to be altered at a later time if more features are implemented due to the requirements changing.

Alice Hodkin – Scrum Master

Above shows the completed tasks of sprint 2, which were assigned using Scrumdesk, with some help from Prince. These tasks provided a clear graphical representation of what each team member needed to achieve during this sprint. When tasks were completed, they could be moved across the board. During this sprint, all of the tasks allocated were completed within the designated time, meaning that in the next sprint, new tasks that need completing can be assigned.

Charles Hackett- Programming-  Charles Hackett Pair Programming

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

In this sprint I pair programmed with Michael Hancock and we began developing the system in Java and created the socket which is used to communicate with the server, we used the ServerSocket and PrintWriter and BufferedReader Java Api’s to code the initial implementation of the system and this allowed us to successfully implement the ‘Helo’ command which is used to acknowledge a successful connection. During these programming sessions we encountered a couple of errors that can be seen in the pair programming log, the first of these was just a few small syntax errors as we where using Notepad and we missed a couple of things before it was compiled, the second error was also a syntax error where we did not use the right syntax in the While Loop as we tried using ‘Null’ instead of empty speech marks. We spent 4 hours coding and the time driving was 50%.

Michael Hancock- Programming

In this second sprint I had the role of developer with an emphasis on pair programming with Charles Hacket. We began work on the back end of the system. This included implementing class designs and the domain model myself and Charles had designed last sprint. Up to this point only work on the systems front end had been done. We both spent about 50% of the time ‘driving’, the rest of the time discussing implementation and trying to spot mistakes. Personally I found this quite a frustrating process since I felt like the person whom was driving, never really needed the help of another person. Rather their interruptions stopped the flow of development. It would have been easier/quicker if we have developed on our own on separate parts of the class design.

Another problem was that we both have fundamentally different programming styles, and at no point had any design pattern or convention for naming variables/functions/classes had been established. This made reading each other’s code a more difficult experience. Aside from this we did discover a few bugs when reviewing the code after. Including a threading issue and incorrect use of java’s .equals(“”) function. The resulting pair programming log can be seen below.