SCRUM Software Development Methodology

Transcription

1 SCRUM Software Development Methodology Software development process or methodology (SDP) provides what to do to undertake and advance a software product in finitely many steps which can be initiated, repeated, defined, managed and optimized consequently. Apparently, the fundamental partitioning of software development process into phases such as the analysis, design, implementation, testing, release and maintenance phases respectively are however, depended on the different SDP to fashion unique approach and technique on how these phases are to be accomplished, including the order which must conform with the principles, rules and pedagogy as reinforced by the SDP. (Lee, 2012) argued in the affirmative that, Software development is a process of communication. There are many approaches helping the development to produce qualified software to stakeholders. This distinctively altogether, asserts that, the discretion of the deliverable expected for each phases are encompassed in the organization of the SDP dialect of choice. SDP is under obligation to make adequate description and decomposition of procedures, activities and tasks required to create desirable outcome (Software product). Advertently, software development starts as an expedition whose scopes is not entirely predictable beforehand but which are discovered and unveiled along the line of the development duration or after it is completed, (Lee, 2012) established the foregoing assertion that, numerous software projects originated through insignificant size and were not disposed to definite requirements pending when the projects have ended; this brands Scrum as most suitable compared to any other development methodologies. Consequent upon the foregoing, agile methodology and more precisely it Scrum variant will be discussed and analyzed in great details. Scrum emerged as agile process for software development. However rather than a complete process or methodology, it is a framework. Therefore as an alternative to

2 providing comprehensive, meticulous explanations of how the whole lot will be completed on the project, considerable option is reserved to the software development team to choose. The idea is so, for the reason that the team will know best how to resolve the difficult they are encountered. For the reason discussed in the foregoing, a sprint planning meeting is designated in relations of the anticipated outcome (an obligation to a set of sorts to be advanced in the succeeding sprint) unlike the case with most methodologies. Scrum is oriented on self-organizing, cross-functional team formation with no designated over all team leaders as every member of the team can switch role interchangeably in the development phases. There are two specific supports individual for the Scrum process, the Scrum Master and the Product Owner respectively. The former assumed the role of the team coach, assisting the team members in ensuring they observe the Scrum principles for the project. The later assumed the responsibility of customers or users, business owner and guides the team toward developing the right product. (Gunga, et al., 2013) averred that Scrum, have productively delivered a solution to the flaws of these customary prototypes. Through additional malleable lightweight processes, agile methods purpose at supplying products earlier, with greater quality and decreasing the risks of project botches by emerging greater value features in shorter repetitions. Suffice to the foregoing, Scrum process is iterative and incremental, therefore the project is fragmented into a sequences of consecutive sprints. Each sprint is time constrained, typically to between a week and a calendar month. The Scrum model proceed with each sprint with a sprint planning meeting, where the product owner and team discuss about the most important in the order of priority items on the Scrum product backlog. The team members consequently outline those items they can commit to and then create a sprint backlog, which represent the tasks to be performed during the sprint. Scrum process recommends that each day of the Scrum sprint is visited with a daily Scrum meeting which is attended by all team members

3 including the ScrumMaster and the product owner. The meeting is use to appraise issues; discuss challenges and status update from each team member and as well as foster team cohesion too. At the finish of each sprint the team members conduct a sprint review with the product owner in attendance to provide feedback about the features which are added. To close the sprint, a sprint retrospective meeting is conducted with all the team members, product owner and the ScrumMaster in attendance to reflect on the past activities of the sprint and opportunities which they present for the future sprints if any. The primary artifact of Scrum project is the software product. The model expects each sprint to complete or deliver a product or system that is potentially shippable at finish of the sprint, other artifacts are the scrum product backlog that is a full list of feature that are not yet added to the product. The product owner always ordered the Scrum product backlog so that the team can accord attention to the foremost item in the ordered list. The product backlog is created by populating it with user stories which is a description of feature from the perception of the user or customer. There is however the difference between the sprint backlog and product backlog, the former is the list of tasks to do by the team while the latter is the list of features to be built into the product. The sprint burndown chart and release burndown chart are other two artifacts which track the amount of work yet to be accomplished in either a sprint or a release. This is useful to determine whether the sprint or the release is on schedule if need be. (Ionel, 2008) however disposed that, SCRUM is a management methodology, developed in order to improve and maintain an existing system or a production prototype. This methodology assumes the existence of a project and some source code sequences, which almost always exist in the object-oriented software development due to class libraries. The Scrum process like any other disposed software development process is driven by roles on whose shoulders rest certain responsibilities within the ecosystem of the whole process. There three fundamental roles on the Scrum project, the Scrum Master, the Product

4 Owner and the Team. The ScrumMaster is responsible for instilling the doctrine and dogmas of the Scrum process on the team and he is there to guide them through as demanded. The product owner represent the interest of the customer and communicate customer requirement to the team for development in a product backlog and he/she is available consequently during the sprint review to ensure that the additional feature conform to the requirement. Lastly, the third role is the team membership of the Scrum process which is formed as self-organized and cross-functional body. There is no team leader appointed as every team member can function in different responsibility in all the phases of the development. This idea draws close team cohesion and together fostering the advantage of one indivisible team-work. (Duraisamy, et al., 2013) argued that, SCRUM is one of the famous Agile methodologies which produces a product during small cycles called iterations and its functionality of product increases during each iterations by adding new properties. The foregoing is where Scrum process draws it strength and the comparative advantage over other methodologies, the fact that requirements cannot be entirely determined before or during a development project disposed the Scrum process where development are segmented to numbers of iterations or sprints as the best approach to such undertakings. Requirements can be developed in a sprint and delivered while additional requirements can be requested through subsequent sprints as scope change is unavoidable occurrence in software development projects. However (Mahnic, et al., 2012) opposed that, Possible loss of management control is one of the greatest concerns when adopting Scrum software development methods in industrial practice. Therefore, monitoring progress of Scrum projects is an important issue in the software industry. This suggests that Scrum process is susceptible to loss of control at the managerial level which can give rise to resources overrun for the development project, it stem from the fundamentals that if control is loss of any engagement, therefore we will be

5 handicap of the scope, cost & budget, human and resource schedule and the quality requirement of the project which can consequently lead to failure. References: Duraisamy, G. & Atan, R. 2013, "Requirement Traceability Matrix through Documentation for Scrum Methodology", Journal of Theoretical & Applied Information Technology, vol. 52, no. 2, pp Gunga, V., Kishnah, S. & Pudaruth, S. 2013, "Design of a Multi-Agent System Architecture for the Scrum Methodology", International Journal of Software Engineering & Applications, vol. 4, no. 4, pp Ionel, N. 2008, "Critical Analysys of the Scrum Project Management Methodology", Annals of the University of Oradea, Economic Science Series, vol. 17, no. 4, pp Lee, R.C. 2012, "The Success Factors of Running Scrum: A Qualitative Perspective", Journal of Software Engineering & Applications, vol. 5, no. 6, pp Mahnic, V. & Zabkar, N. 2012, "Measuring Progress of Scrum-based Software Projects", Electronics & Electrical Engineering, vol. 18, no. 8, pp Bibliographies: NATHAN-REGIS, B. & BALAJI, V. 2012, "Evaluation of the most used Agile Methods (Xp, Lean, Scrum)", International Journal of Engineering Science & Technology, vol. 4, no. 1, pp Paasivaara, M., Durasiewicz, S. & Lassenius, C. 2008, "Using scrum in a globally distributed project: a case study", Software Process: Improvement & Practice, vol. 13, no. 6, pp Salo, O. & Abrahamsson, P. 2008, "Agile methods in European embedded software development organisations: a survey on the actual use and usefulness of Extreme Programming and Scrum", IET Software, vol. 2, no. 1, pp Suscheck, C.A. & Ford, R. 2008, "Jazz improvisation as a learning metaphor for the scrum software development methodology", Software Process: Improvement & Practice, vol. 13, no. 5, pp

6 Hajjdiab, H., Taleb, A.S. & Ali, J. 2012, "An Industrial Case Study for Scrum Adoption", Journal of Software ( X), vol. 7, no. 1, pp Lukasiewicz, K. & Miler, J. 2012, "Improving agility and discipline of software development with the Scrum and CMMI", IET Software, vol. 6, no. 5, pp