Project Practice Guide.txt

Agile software development (ASD) has been promoted worldwide as one of the most successful approach for software development project. There are many ways to implement Agile in a team since it is the method designed for customization. Based on the organizations culture and values, they can have a different set of practices and principles (reference).  Knowing what Agile methodology is best suited the project is important. In this case, we suggest the project team to apply Scrum methodology to successfully deliver the project in a timely manner.
 Collaboration & Communication
•	Daily meetings: the team has to hold short meetings on a daily basis, usually around 15 minutes. This is a good way to keep people aware of the process of the project, as well as knowing how other teams are doing. The team can discuss about what we have done, what we will do and if there is any blocks.
•	Open office space: the development team should locate together in an open environment to facilitate face-to-face communication. (Lagerberg, Skude, Emanuelsson, & Sandahl, 2013)
•	Working in a Scrum team: people will work in a Scrum team which consists of these roles:
-	Product owner: who has the authority to decide what features and functionality the team has to build and how to build them. The product owner has to meet regularly with customers to keep them aware of the team process. Besides, they ask for feedbacks and what features the customer wants next. Product owner works very closely with scrum master, designer and team members to clearly figure out what the scrum team is trying to achieve. He/she has to make sure everyone is informed of what they need, clarify any issues and helps in decision making process. Product owner will take the responsibility for the overall success of the solution being developed. Being such an important role, identifying and appointing someone who qualified enough for it is important.
-	Scrum master: who makes sure everyone understands Scrum values, principles and practices. Scrum master plans and hosts all Scrum practices which includes daily stand up, sprint planning, … He/she assists the team in identifying blocks and works closely with the product owner, team member and the organization to remove them. Acting like a coach, Scrum master aids team members to understand their roles and responsibilities. To sum up, the Scrum master helps the Scrum team to develop a high-performance, organization-specific approach. 
-	Development team: typically involve five to nine people who have the same skillsets needed to develop a good-quality software. Development team members do testing, documenting, testing code daily besides taking part in Scrum practices. They get information needed from the Product owner and working closely with Scrum master to remove any impediments.
•	Team agreements: every team should specify a team agreement. There is a number of benefits of having a team agreement. It is a foundation of creating trusting relationship which strengthens the team’s infrastructure. Moreover, it eliminates assumptions about what is expected of everyone which results in better performance and trust. (Thakore, 2010)
•	Sprint retrospective: a meeting will be held at the end of each sprint. Only Scrum team members are involved. This is an opportunity for the team to reflect about what they have done well and what could be improved for the next sprint.
•	Sprint review: a meeting which includes Scrum team members and other stakeholders at the end of the sprint. It shows the current sprint working and the demonstration of the deliverables. Sprint review is a good way to make stakeholders feel involved and informed as well as increase their interests. 
Requirement Engineering
1) Stakeholder: Knowing how to categorise the stakeholders into different groups is essential. It helps the firm to capture all key stakeholders that are important to the project, as well as find an efficient way to manage this group of stakeholders.
•	Stakeholder analysis: identify and classify stakeholders using Stakeholder Typology (Mitchell, Agle, & Wood, 1997). There are 3 quality classes of stakeholders which are: power, legitimacy and urgency. By this way, the development team does not only make sure that they do not miss any potential stakeholders but also figure the way how to deal with different type of stakeholders. 
 
(Picture URI: https://blackfishandseaworld.files.wordpress.com/2015/03/image02.jpg)
Here are some key stakeholders that the firm should focus on:
o	Definitive Stakeholder: who have all power, legitimacy and urgency. The organization should have immediate attention to give priority to that stakeholder claims.
o	Dangerous Stakeholder: who have power and urgency but no legitimacy. This kind of stakeholder can be possibly violent and be a threat to the firm.
o	Dependent Stakeholder: mostly the users. They lack power but have the right to claim, since users are the ones that will bring benefits to the firm eventually. Their claims should be respected and noticed.
And some stakeholder groups that the firm can be less concern about:
o	Demanding Stakeholder: those with urgent claims but having neither power nor legitimacy, could be bothersome but not dangerous.
o	Dormant Stakeholder: they hold the power but yet do not have any interest or legitimate relationship with the firm. Therefore, their power remains unused. One example of dormant stakeholder is the government.
•	Stakeholder Documentation: register all identified key stakeholders and specify different management strategy to them using Stakeholder Register and Stakeholder Management Strategy documents.
2) Requirements: since the firm idea has been promoted in an international contest, the firm should have a clear idea of what should be expected to see in the game. However, if the organization wants to expand the scale of the game and collect more requirements. Here are some suggested methods for collecting requirements:
•	Requirements collection
o	Interviewing
o	Prototyping
o	Observation
o	Questionnaires and surveys
o	Benchmarking
•	Functional & Non-functional requirements: the organization should have both type of the requirements. While functional requirements are the features of the game, non-functional requirements are related to performance, security, usability and compability.
•	User story: for software development project, user story is a good practice to manage the functional requirements should be implemented. It is a story which describes functionality that will be either valuable to user or purchase of a system or software. User story has 3 aspects: a description, a conservation and a confirmation. A good user story is independent, negotiable, valuable, estimable, small and testable.
•	Product backlog: it is a prioritised, estimated list of user stories. It decides which user stories are more important so it should be implement on the first release, less important functionalities can be moved to later iterations. Product backlog should never be frozen, it is regularly updated throughout the development process. Product backlog refinement should be done in every sprint.	
Project Planning and Tracking
•	Sprint planning: there is a sprint planning in the beginning of every sprint. It includes all Scrum team members work together to create a backlog of specific stories that have the highest priority for the product. High-priority stories are prioritised to be implement in earlier sprints. A sprint goal is defined to show what the upcoming sprint is supposed to achieve.
•	Effort estimation: this is an essential part and also the hardest part of every project planning activity. Estimation is complicated because different people may have many different thinking and ways to approach a problem. There is a really high chance of giving an over or under estimation rather than an accurate estimation. In our opinion, it is nearly impossible to achieve an exactly accurate effort estimation. Subjective estimation techniques are the one that most used in ASD. For size metrics, story points and use case points are really popular. However, all current effort estimation techniques need improvement in accuracy. (Usman, Mendes, Weidt, & Britto, 2014)
•	Burn down Charts: a burn down chart can visualize the progress that you have done and what you have left in completing a user stories for a given period of time.
•	Gantt Chart: the team can use Gantt chart to display project schedule information by listing project activities along with their start and finish date in a calendar format. Milestones can also be added to the Gantt chart to emphasize important events or accomplishment.
•	Critical Path Analysis: critical path can be easily seen through a network diagram. It is the longest path in the network diagram and at the same time determine the earliest time a project can be finished. Tasks belong to the critical path must be started or finish on time, otherwise the project completion will be delayed. Side tasks which are not part of the critical path offer some free slacks. The fact that they can be postponed for a certain amount of time without affecting the project completion date give the team some flexibilities of how and when to do these tasks.
•	Program Evaluation and Review Technique (PERT): this is a technique the team can used to estimate the project duration in case of high degree of uncertainty. This is the formula: 
   PERT weighted average =  optimistic time + 4X most likely time + pessimistic time
					                       6
•	Source version control: having a source version control is compulsory to develop software in a team environment, this allows developers to collaborate effectively. It keeps track of the changing states of files over time and merge the contribution of multiple developers. Source version control does not only work great with code but also with documentations. There are multiple benefits of using a version control: data integrity, increased productivity, record keeping automatically, accountability.
Managing change
Changing requirements is a natural characteristic of an agile software development project. Change could be made in any process or anytime where and when appropriate. Fortunately, agile software development method is very flexible. It embraces and accepts the idea that requirements can evolve during the project development. Managing change is inevitable in Agile since there are so many reasons that requirements are not stable from the start to the end in a project: 
•	Team mistake: the team failed to identify an important requirement that was later discovered by a stakeholder.
•	Political issues: there could be a power shift among different stakeholders. Therefore, the user story prioritisation also needs to be changed.
•	Legislation changes: state laws and federal laws change during the development could possibly affect the organization project.
•	Market changes: sometimes changes are done due to the competition among different companies.
•	Stakeholder requests: new feature that stakeholder wants to add on during the project development.
Handling changes in Agile and Scrum particularly could be done often and elegantly:
•	Product backlog Grooming: refer to 3 principles: create and refining product backlog items, estimating product backlog items, prioritising product backlog items. Product backlog grooming should be done every time a change is specified which means any new requirements will have to undertake a prioritising and estimating process. Other existing requirements also have to be modified accordingly. 
•	Stakeholders actively involved: continuously receiving stakeholder’s feedbacks and their active participation can ensure that all product backlog items are properly chosen, avoid missing any potential requirements. Sprint review is an appropriate time to work closely with stakeholders.
•	No change management during iteration: change should be avoided to happen during the middle of a sprint. If there is a chance request happens at this time, it should be left to the next iteration. Changes which are done during an iteration can result in defects due to inadequate modelling. These are regression defects cause of unforeseen side effects of architectural and code changes (Kannan, 2011)
•	Documentation regularly updated: all documents have to be revised whenever a change takes place. Record different versions of document is also essential.
Quality assurance
Testing is an obvious activity for quality assurance. It ensures the product created does properly what it’s supposed to do. There are so many scenarios that makes the software do not work, we need to cover all of them by having different levels of software testing. Quality assurance is important to deliver the best products that the firm can and also the cost of project failure in testing is really high. There are 2 types of testing which are manual and automated. The firm need to be able to implement properly both of them.
•	Manual testing: testers play a role as an end-user and verify all features of the software by finding all possible defects. Manual testing is preliminary testing, must be carried out prior to start automating the test cases. There are different stages for manual testing such as unit testing, acceptance testing…
•	Automated testing: the product will be tested using scripts written by tester. Automated testing also correlates very well with the deployment of continuous integration. They boost the development team productivity, improves code quality and reduces the risk of project execution. Developers are encouraged to write and submit corresponding automated testing cases when they submit source code (Lu, Yang, & Qian, 2014). However, automation has its own limitations:
o	Automation cannot replace manual testing: not all tasks can be easily automated. Some tasks require manual testing specifically.
o	Test automation could be hard to maintain due to the rapid change in technology and evolution of software products
o	The needs of skilled people: writing automate tests are not an easy task. Software development skills, domain and system knowledge are required for a skilled automate test writer.

•	Acceptance testing: are used to verify that user stories are developed in an expected way from customer. They are written in business domain language and developed in a conversation between the developers, testers and product owners. Acceptance tests can be done both manually and automatically. The software team will ask the user to be the actor in testing our software. Through the use of UAT it can ensure that software has practical uses in a real life situation as is functioning as intended by our users. By using UAT the team can effectively test whether or not the system can support day to day activities and is robust enough to be considered a quality abd professional product by users.

•	Unit testing: is a small piece of code run in isolation to test a public function or method. Unit tests are fast to write, operate and easy to maintain. Unit testing are often written by the developers during the development. 
	The team will test every bit of software whenever a section of functionalit is completed. This is to ensure that 
	no bugs are introduced into the architecture of the software as a whole
	
•	Usability testing: Evaluating the usability of the software product is very important at the end of software development process. The advantage of this testing is that it will help the users satisfy when using the software, ensure no failure at perfoming any task by users and enhance users experience. The software team will gather some participants act as users to perfome some required tasks that are belived to be critical software activities. If the users complain "cant" or "wont" do the task correctly, they need to find the solution to that problem, and test the new design with users again to make sure it satisfy them before releasing final product to the market.

Quality assurance checklist:
We have created a checklist to ensure quality for every deliverable. This is to make sure nothing is overlooked and the project retains quality for all deliverables. Here is a sample of the checklist per deliverable:

-Process/Deliverable

-Quality Planning

-Quality Checking

-Quality Improvement

-Should we stop doing this?(reason why?)
        References
        http://www.oracle.com/webfolder/ux/applications/uxd/assets/faq/how-to-conduct-usability-testing.pdf