3.3.1 Test Driven Development
For our project we followed the Test Driven Development (TDD) style of programming. TDD allowed our group to efficiently write code by providing constant feedback on our code’s functionality. TDD is the process of writing simple failing tests before writing the functional code to complete these tests. The next step is to write just enough functional code to pass the new tests. Once the tests pass the next step with TDD is to restart the cycle and write another simple failing test. Figure 10 shows the TDD process from start to finish. Development cycles until all
functionality requirements are completed.
The main goal of TDD is to require a programmer to write code using small steps and prevent excess code. Traditional programming is done by writing code first, then writing tests that in theory should pass. When using traditional methods, debugging a failed test can be very time
consuming due to difficulty finding the problematic code. TDD allows the code design to adapt to the programmers changing understanding of the problem more easily than traditional development. Test Driven Development allowed our group to stay focused on small tasks at a time and progress in an iterative manner. We used TDD over the course of our entire project as long as the situation allowed.
3.3.2 Pair Programming
Our group used pair programming to write our code, which involved two of our group members sharing one computer and writing code together. The programmer at the keyboard is called the “driver” and the other individual is the “navigator”. Pair programming allows both individuals to share knowledge, exchange ideas, and help each other stay focused on the current task. Pair programming greatly improved our design process and code quality by forcing discussion, and allowing questions to be raised, on the best practices to complete a task. Two sets of eyes were always looking at the code, which reduced the number of errors and improved our programming efficiency.
3.3.3 Scrum Planning
Our team used the Scrum framework to plan out and execute our project. The Scrum framework outlines the process to successfully complete a complex problem as shown in figure 11.
Figure 11: Scrum framework
The first step is to write up all user stories necessary to complete the project. Our sponsor created user stories to fulfill the ultimate design and functionality for the service registry based on user requirements. The Scrum framework groups the stories into sections called sprints which, for our project, lasted two weeks each. We assessed the stories by difficulty and assigned relative values to each story. In Scrum, each sprint should ideally have stories with comparative levels of difficulty. Also, the stories within each sprint are organized by dependencies on other stories to provide a clear path for completion. During each sprint there are daily meetings called stand-ups where each
member of the team says what they accomplished yesterday and what they plan to do today; as well as, any current problems they are having in accomplishing their story. Figure 12 displays the layout of the scrum board and demonstrates the movement of tasks as they are completed. The daily scrum meeting allowed our team to discuss the status of the stories.
Figure 12: Scrum board layout
Before a story can be moved into the done category on the board it must meet the requirements that our team agreed upon. Figure 13 illustrates the steps that must be completed in order to meet our team’s definition of done. During our sprint-planning meeting, we also discussed
the steps in figure 13 and decided that integration tests are optional to meet the definition of done because they are not always feasible for a particular story.
Figure 13: Definition of done
At the end of each two-week sprint our goal was to have a deliverable that can be presented in its entirety with all the stories completed. We aimed to present a demonstration (demo) to our sponsor at the end of each two-week sprint. Also, at the end of a sprint our team has a retrospective that reviews how the sprint went. For this discussion each team member wrote down actions they wanted the group to stop doing, do less of, keep doing, do more of, and start doing. Then we would discuss each category (Stop, Less, Keep, More, and Start) as a group and set goals about how we wanted to improve the next sprint.
Our project involved using the Scrum framework to create an internal service registry for JPMorgan employees to use when looking for a company created service application. Our team was
employees to upload a new service they have created. Also, we focused on designing a back-end for interfacing with our newly designed database that stores all the information about current services.
We broke our project up into three sprints that were each two weeks long. For the first sprint, we focused on setting up the database schema in Powerdesigner and creating the framework for database interactions using Java. For the second sprint, we worked on setting up the user
interface and connecting it with the back-end. For the third sprint, we concentrated on adding more functions to our service registry. The Scrum framework kept our team focused and gave us a clear plan of the order to complete tasks in.