SCREAM (SCRUM TEAM MANAGEMENT TOOL)

Transcription

1 SCREAM (SCRUM TEAM MANAGEMENT TOOL) HONOURS PROJECT PROPOSAL 2010 COMPUTER SCIENCE UNIVERSITY OF CAPE TOWN Christopher Jolly Bryan (Cliff) Siyam Alexander Kivaisi 1. Project Description Scrum is a useful agile and iterative methodology for software development. To this end, it is implemented in a lot of software development companies as it can adjust to changing requirements more easily than other methods such as waterfall, spiral. Light on documentation, Scrum is also customizable and thus most companies do not always implement strict Scrum but can use some or most of its features and combine with other methods or any nuance the development team already has. Korbitec is an example of one such company that uses their own customized version of Scrum. Software tools have been created in order to complement Scrum; however, they do not take account of the specific requirements that individual companies have. Some commercial software does try to do this but it ends up being somewhat complex to configure. To this extent, we are proposing to develop Scrum software that specifically targets the needs and usage patterns that are specific to Korbitec. 2. Problem Statement Korbitec is a software development company producing law-based programs. They have implemented Scrum as a methodology to manage their software development process. Currently they use a tool by the name of ScrumWorks. However, they do have some problems with this product. One of them is that as this is done using Java and thus the GUI is Swing based, it does not have a Windows look and feel to it and may not be the easiest or simplest interface. Another problem is that due to their Scrum customization, certain features of ScrumWorks is not needed but ScrumWorks insists on that feature being used via a popup during the procedure. This product is intended for use by the Product Owner mostly and will be used mainly in the Scrum Planning and Scrum Review meetings. In meetings with the team members involved, they detailed a list of requirements for this product (which are mentioned below). The two main key points that need to be satisfied is 1) that the user interface be easy to use so as not to

2 interfere and distract during the meetings and 2) it must have a summary/report view to show at a glance the stories and whether they were completed. 3. Procedures and Methods 3.1. Design features Simplicity and efficiency of the user interface is the most important, as the tool will be used during planning sessions, so the tool should not get in the way. Multi-user enabled Product/Project management which includes the backlog Searching for stories by any of the project descriptors (date, owner, name ) is also a requirement. Providing a given story list in a format that can be included in an or printed would be a very useful feature. Printed story cards for a sprint, including description, name and story points (colour codes, unit work ). A graph of story points committed versus story points completed. & attachments (an optional extra for inputting data) 3.2. Development platform As the system is required to be a Windows program the platform will be solely Windows. Development will take place within Visual Studio 2010 using C# and WPF. The database for the backend storage will be SQL Server 2008 R2 Standard. Source code control will be done via a central repository with subversion run over the Apache Web Server Implementation strategy Considering this project is mostly about Scrum and seeing its benefits, we have decided to do this project the Scrum way. We have decided to implement a Sprint of 1 week. At the beginning of the Sprint, we will choose the feature or features we think we can manage to implement during that week. This feature(s) will be then broken into smaller subtasks and each person will be allocated a certain amount of these tasks. During that week, the specified feature(s) will be developed, debugged and tested. Each day (at least during the week), we will hold a brief Daily Meeting as done by the Scrum. This will help us keep focused on the feature at hand and allow us to discover any impediments as early as possible and to eliminate them. At the end of the Sprint, we will have our weekly meeting with our supervisor (which is the reason why we chose a Sprint to be 1 week). As the Sprint has just finished we envision being able to demo a new piece of functionality each week Testing plan Testing will be done internally. For any new piece of functionality, it will have some unit tests and initial usability testing done during that Sprint. Once there is enough functionality in the product, we will start dog fooding it. In essence, this entails that we actually use this software

3 ourselves in the manner that Korbitec will be using it. This will allow us to get a proper feel of how easy the software is to use and we can improve it as we discover any problems. Ultimately, the final testing should come from the Korbitec team that is going to be using this software. As this is the group that is going to use the software it is important that they feel satisfied with the features provided and its usability 3.5. Expected challenges We do not expect any major challenges during most of the project. However, some areas may present challenges at first. The first that we will mention is that not everyone in the group knows C#. As the project is being written in C# this could be a problem. Looking at the timeline shows that this is probably not a large problem apart from maybe during the first week of the project: one can see that after the first week there is a long vacation in which we can spend time becoming familiar with the language. In addition, some of the members have not had too much experience in debugging code. This for them could be a challenge unless they do some practicing during the vacation. 4. Ethical, Professional and Legal Issues As a normal software engineering project, we do not anticipate any ethical issues of the form that would occur in the research type projects (e.g. doing surveys etc.). As far as we can ascertain there is no need for any ethics clearance needed for this project. The following is a brief list of possible ethical issues that may arise in software development: Using open-source code without giving credit Using any open source code that is covered by a license is illegal if it is not credited. The main problem is when companies use it without the acknowledgement. For our project, we do not foresee any issues in this regard, as this is a tool customized to a specific company. The features that need to be implemented are highly likely to be able to be implemented without any external helper libraries. However, if the need arises that such code needs to be used, we will abide by the license and give credit to the authors of that library. Using illegal software This would be using any pirated or illegal software for the development (such as a cracked Visual Studio etc.). As the software will is either available to us through the MSDN Academic Alliance or is freely available open source software this should not be a problem for the project. Reverse engineering code Reverse engineering is illegal in many countries. There is no need to do any reverse engineering to implement any features that needs to be implemented thus this is a non-issue for us. Taking talent from competition

4 The likely-hood of this happening is quite remote as this project has been tasked to us three and it is not possible to bring any other Honours students into the team as they also have their own projects. There are also issues regarding intellectual property. It is currently uncertain as to whether it is legal for Korbitec to use the software we have created live in their business. This will need to be investigated although producing the proposed software in this project does not depend on the outcome of this issue. 5. Related Work Since the mid-90 s with the start of Scrum, Scrum tools have been sprouting out into the market. Both commercial and Open Source tools are being used in the software development industry. Companies choose their tools to best fit their Scrum teams implementation of the methodology. Amongst the many commercial (ScrumWorks, ScrumNinja, VersionOne, Target Process, Scrum for Team System...) and open source tools (XPlanner, FireScrum, IceScrum, Scrum Tool, Scrum Time...), we have chosen two prominent ones to look at, ScrumWorks and XPlanner. Figure 1: ScrumWorks Feature Comparison ScrumWorks is the most widely used Scrum (and agile) tool in the industry with nearly 150,000 active users. ScrumWorks is designed to be as intuitive and streamlined as Scrum itself. Its features (see figure 1) completes the essentials needed to manage a Scrum Project, by definition. Some of the features it implements are not required by Korbitec. Its features that

5 allow for distributed Scrum teams operating on a project are irrelevant to Korbitec who, despite their multiple branches, only has one branch developing software. XPlanner is mainly an Extreme Programming tool but it supports Scrum. It was a major tool on the market with over 45,000 downloads of the last version 0.7b. No more releases are scheduled. XPlanner s set of features, like ScrumWorks, contains the basic Scrum functionalities, but with a few drawbacks mainly because of the loss in support. It also implements a multiple click interface, which inherently makes its use more time-consuming than helpful. Their common platforms are Java, MySQL (or other relational database management system), and they both run on Windows, Mac, and Linux systems. Figure 2: XPlanner GUI 6. Anticipated Outcomes 6.1. System The Scrum Team Management software implemented in WPF should be expected at the end of the project. This tool should be able manage (adding, updating and deleting) product backlog as well as sprint stories items for each project and storing them in the database. It should also be able to search for stories items by any of the text fields, produce sprint planning summary in a format that can be included in an , print story cards for daily scrum meeting and produce a graph of story points committed versus story points completed Expected impact With the success project, we expect the management system to positively influence the scrum development team at Korbitec Company. The system will not get in the way of the users during

6 the meeting and will be able to provide the correct feedback at the call of a button. This feedback will be of important use during a retrospective meeting and will help the planning of the next Sprint Key success factors The tool will be primarily used by scrum development team at Korbitec. Therefore, the success of the project will depend mainly on evaluation of the key features the tool will provide to the team. Different evaluation techniques such as observation methods, interview methods and other usability testing techniques will be apply to measure the understanding of the user and interface problems towards the system. We will also apply the dog food method which will help us to determine from ourselves the usability and flexibility of the system during the project development as it progress. Simplicity and efficiency of the user interface as to be the most important characteristics will guarantee the success of the project. All of the previous just leads to the final measure of success: Is the development team from Korbitec satisfied that the system meets all of the original requirements set by them? 7. Project Plan 7.1. Risks Risk ID Risk Probability of Impact of Risk Risk 1 Group Member leaves Medium Medium Late the group delivery/work 2 Group Member either felt sick or does not complete their section Consequences Mitigation overload Low Medium Delay delivery of the system 3 Requirements not met Medium High Will lead to failure of the overall project 4 Conflicts within the team Medium High Might lead to wrong delivery(design/ development) or Late delivery because people don t help each other to resolve problems Delegation of tasks to other members Eat well every day!!! Daily scrum meeting will help each other to solve our problems Confirm with the stakeholders after requirement gatherings Resolve problems as soon as possible 5 Certain sprint stories Medium Medium Might lead to Distribute to

7 might be too big for one person to handle 6 Inadequate communication between project team and stakeholders(korbitec) late delivery other members or solve others problems through daily meetings Medium Medium Might Regular meetings should be set fortnightly Timeline See appendix A for timeline table and see appendix B for Gantt chart Resources Required Hardware Only the standard workstations and our laptops our necessary as the software (listed below) will work on them Software Microsoft Visual Studio Main development IDE including GUI design SQL Server 2008 R2 Standard - Database back-end Source code Management Tool (E.g. Subversion) Apache Web Server - will run the subversion server 7.4. Deliverables Project proposal Final software system Poster Web Page Project report Reflection paper 7.5. Milestones See appendix A 7.6. Work Allocation As this software engineering project is complex and does not have clearly defined boundaries, dividing the work between the different tasks/features leads to too many inter dependencies

8 between these features. As the requirement is for each person to have a part that can be done separately to the others this way, unfortunately, does not work. A possible option is to have each of us implement our own version of the proposed system. Thus, each person is not dependent on the others and can be marked separately. However, doing it this way will be a lot of work and may be more than we can handle. The allocation eventually chosen is to have each of us take different roles in each Sprint. As there are three of us there will be user interface designer, core developer and tester. These roles will not be static for a person and in each Sprint they will be allocated a different role. Thus by the end of the project each member would have been allocated to each of these roles at least once. This is more defined than the initial choice and should a member leave, one can leave out one of the roles. At the end of the project, having been in each of these roles will provide enough for the individual write up and also one can easily analyze what each person did during that Sprint. 8. References [1] Collabnet, Inc. Scrum Software, Development & Scrum Training - ScrumWorks CollabNet, Inc.,2010, [2] XPlanner. XPlanner Home, 2010, [3] Comparing Open Source Agile Project Mangement Tools Linux.com, 2010, 9. Appendices: Appendix A: (Timeline table) Milestones Dates Literature Survey Project Proposal Project Proposal Presentation Revised Proposal Inclusion of Project proposal and Timeline on Project Web Sprint 1 First Half 13 March -3 April 4 April-12 April 13 May-17 May 19 May-28 May 1 June 28 May-4 June

9 Break Sprint 1 Second Half Background/Theory Chapter Design Chapter Sprint 2 Sprint 3 Short Vacation Sprint 4 Final Prototype Implementation and Test Complete. Coding Complete Outline of Complete Report Final Complete Draft of Report Final Project Report Handlin Poster Web Page Reflection Paper Project Demonstration Final Project Presentations(Preparations) 7 June-26 July 26 July 2 August 26 July-30 July 8 August-26 August 3 August- 17 August 18 August- 1 September 6 September 10 September 13 September 27 September 29 September 29 September 30 September-4 October 5 October-11 October 12 October-25 October 26 October-1 November 2 November-4 November 1 November-8 November 9 November-12 November 3 November-8 November 9 November 18 November

10 Appendix B: (Gantt chart)