Agile Software Development Process - Coursework Example

Agile Software Development Process Introduction Agile software development process is a creative process’ methodology that applies a level of pragmatism and anticipates the need of flexibility into delivery of finished goods. Agile software development focuses on testing and keeping the code simple as well as delivering functional bits of application when they are ready. The main goal of agile software development is to develop client’s approved parts as the project proceeds other than opposing the delivery of huge application at the end of the project. An agile manifesto is a formal proclamation of four key values and twelve principles that directs a people centric and iterative approach to software development (Akins, 2013). The paper will explain how the agile development process works basing on stand-up meetings, product and sprint backlogs as well as project charter. In addition, scenarios will be utilized to give examples of techniques such as class diagrams, activity diagrams and stakeholders. How the agile development process works The manifesto for agile software development also known as agile manifesto is a formal proclamation of twelve principles and four key values to help guide people centric approach and iterative approach to the development of software. Agile software development targets delivery of functional bits of application, keeping codes simple and testing often applications when they are ready. The software was created as an alternative to heavy weight and document driven software development processes that includes the waterfall approach. The 4 core values of the agile software development emphasizes on various issues that includes; individuals and interactions over tools and processes, customer collaboration over contract negotiation, working software over comprehensive documentation as well as responding to change over following a plan (Aoyama, 2010). The 12 principles that have been laid down by the agile manifesto have been adapted for managing IT related projects and variety of businesses including business intelligence. They include; customer satisfaction through continuous and early delivery of valuable work, breakdown of big work into smaller components that can be tackled easily, recognising that teams that are self organized are able to perform work better, providing of motivated individual with support and environment they need and offer them trust to get the job done (Carroll, 2012). The other principles includes creation of processes that promote sustainable efforts, maintenance of constant pace for work that is already completed, welcoming of changing requirements , assemble of the business owners and project teams on a daily basis throughout the project. Moreover, other principles entails harnessing change for competitive advantage, continually seeking excellence, measuring progress by the amount of completed works as well as having the team reflecting on their activities and how to become effective and then adjusting and tuning behaviour accordingly (Hoda, Noble & Marshall, 2012). A project charter is one of the moist significant documents that can be created in a project and it is important that all the stakeholders participate in the development. It aligns stakeholders, balances intention and offers an agreed upon definition of success. Even a charter may be one page long; it is often challenging to craft an efficient document. It should take a few hours to create and even a whole day for a small project. The content of the charter has to be arrived at by basing on consensus from stakeholders. An effective agile project charter should have three key elements that include vision which is the higher reason or purpose of the existence of the project. It should also have a mission that states what the organization will do in the project in order to achieve its higher purpose. The last key element is success criteria which are management tests that explain effects outside solutions. Another tool that is often utilized as part of the agile project charter is the success sliders (Hoda, Noble & Marshall, 2012). Sliders are often utilized to indicate the relative significance of projects and offer guidance when potential conflicting decisions arise. Stand up meetings are not inherently agile even they are mostly associated with agile development methods such as extreme programme as well as more recently established scrum. This type of meeting is significant especially in environments where teams have some degrees of self management. Various approaches can be considered when stand up meetings are being introduced. The team members should 1st is introduced to the objectives of the meeting. The team members should be trained in the practices of the meeting. The organizer should ensure that the team members are familiar with set of rules that governs the meetings. The third approach is to ensure that key logistics and specifics for the meeting are determined. The last approach that should be considered entails ensuring that effective and efficient stand up meeting is achieved. The team should be able to decide collectively the aspects of the implementations that ought to be improved, abandoned or continued (Kruchten, 2011). Successful project teams should be able to adopt numerous methods of ensuring the team is active through identifying problems and ensuring that progress is developed continuously through achievement of the goals of the project. Stand up meetings have become a common phenomena especially in agile software development. Stand up meetings have several goals that includes; communication of the ongoing project, reinforcing the sense of the team, reinforcing focus on the right things, support improvement as well as helping begin the day well. Stand up meeting should have a good start by giving energy to the team. Energy comes from instilling a sense of urgency and purpose. A clear understanding and sense of purpose should be implemented. People should have shared direction for the success of the meeting. The other part of stand up meeting entails exposing challenges faced to allow better improvement. The team should be able to share ideas and better techniques. Additionally, the stand up meeting should enhance a focus on directing work through the system with an intension of aiding in achievement of objectives. Effective teams are often built regular working, communication as well as helping each other in the achievement of the set goals (Kruchten, 2011). The meeting should therefore, support the development of an environment that allows people to raise problems and come up with ways of solving them. The meeting should establish mechanisms that can help in answering the questions raised. The agile product backlog is a prioritized features list in scrum. It has all the descriptions of the characteristic that is desired in a certain product. During its application, it is never necessary to begin a project with an upfront and lengthy efforts aimed at documenting all the requirements. Ideally, a scrum team and the owner of the product often start by writing everything they think down for the agile backlog prioritization. The product backlog often seems to be more than enough and is often allowed to change and grow as more is learned about consumers and products. A typical backlog has the following items, bugs, features, knowledge acquisition and technical team. The predominant way in which the scrum team expresses their characteristics on the agile product backlog is often in use stories form, which are simple and short description of desired functionality often told in the perspective of the user. The bug often describes something unique that a user wants. Knowledge acquisition and technical work belongs to the agile backlog. An example of technical work entails upgrade of the workstation of the developer to windows 7 (Linkevics, 2014). The product owner may show up with the prioritized agile backlog at the sprint planning media and describes the top item in his list. The team may utilize such an opportunity to determine the item that needs completion as well as item to be moved to the sprint backlog from product backlog. Sprint backlog is a task that is identified by the team and completed during the scrum sprint. During the scrum team meeting, the team often selects come product backlog items in the form of user stories and then identify the tasks that are necessary to complete each story. Most team often approximate the number of hours that are required to complete the task (Linkevics, 2014). The agile software development is also associated with the formation of class diagrams. UML2 class diagram are the mainstream of design and object oriented analysis. The class diagrams indicates classes of systems, operations and attributes as well as their interrelationship which includes association, aggregation and inheritance. Class diagrams have been utilized for various purposes including both domain and conceptual modelling as well as detailed design modelling. Class diagram are the mainstream of design and object oriented analysis. Agile class diagrams show the classes of systems, operations, their interrelationships and attributes of the classes. Class diagrams are utilized for purposes such as detailed design modelling and domain modelling. Activity agile diagram are often utilized for processes modelling, for modelling the logic captured by usage scenario or the one captured by the single use case as well as modelling for the detailed scenario of a business rule. They are often object oriented equivalent to data flow diagrams and flow charts from structured development. Conclusion Agile software development is a group of software development methods in which solutions and requirements evolve through collaborations between cross-sectional and self-organizing teams. The benefits of the development are unquestionable as a result of its diverse applications. Agile software often provides a lot of opportunities for the team engagement and stakeholders before after and during each time-boxed input ('Agile Development Practices Conference Advertisement', 2010). By allowing participation of the project team and clients and providing more opportunities for the team to be able to identify the vision of client, there is a higher chance of collaboration that will exist. Stakeholders will also gain trust in the ability of the team to deliver high quality software when they get the opportunity to witness tangible results. References Agile Development Practices Conference Advertisement. (2010). IEEE Softw., 27(6), c3-c3. doi:10.1109/ms.2010.136 Akins, A. (2003). Agile software development [Book Review]. IEEE Softw., 20(1), 97-98. doi:10.1109/ms.2003.1159039 Aoyama, M. (1998). Web-based Agile software development. IEEE Softw., 15(6), 56-65. doi:10.1109/52.730844 Carroll, E. (2002). Lightweight and agile software development. Ubiquity, 2002(March), 1. doi:10.1145/512526.512514 Hoda, R., Noble, J., & Marshall, S. (2012). Documentation strategies on agile software development projects. International Journal Of Agile And Extreme Software Development, 1(1), 23. doi:10.1504/ijaesd.2012.048308 Kruchten, P. (2011). Contextualizing agile software development. J. Softw.: Evol. And Proc., 25(4), 351-361. doi:10.1002/smr.572 Linkevics, G. (2014). Adopting to Agile Software Development. Applied Computer Systems, 16(1). doi:10.1515/acss-2014-0014 Read More