324 Chapter 8
XP is called "extreme" due to its taking programming practices to so-called "extreme' level (e.g., daily interactions, working software, testing, etc.) which leads to more responsive to customer needs ("agile") to achieve better quality of software development. For example, being taken to the extreme, codes are written and reviewed continuously between a pair of programmers. Both Scrum and XP are Agile, but they are different in that they have different focuses during the agile process. Scrum is focused on managing iterative development activities, that is, Scrum is seeking good management skills in SDLC. Therefore, Scrum is more business emphasis. Whereas XP is focused on more agile engineering approach - quick developing and testing from immediate feedback between two persons; it is seeking good software development techniques in a small group (e.g., two persons). Therefore, XP is more technical emphasis. As such they are complementary. Scrum can adopt many XP software engineering techniques; similarly, XP can apply Scrum's management practices to manage the coding, testing and feedback cycles.
:)
Appendix A - Project Management Project is a temporary endeavor undertaken to create a unique product, service or result. (https://www.pmi.org/about/learn-about-pmi/what-is-project-management) Project management is the application of knowledge, skills, tools, and techniques to project activities to meet the project requirements. (https://www.pmi.org/about/learn-about-pmi/what-is-project-management) Project management processes includes project initiating, planning, executing, monitoring and controlling, and closing. (https://www.pmi.org/about/learn-about-pmi/what-is-project-management) Managing a project primarily manages the following five factors. Scope Time Cost Quality Risk
A project team consists of a project manager and team members. A project manager is the person responsible for accomplishing the project objectives. A project manager is a client representative and has to determine and implement the exact needs of the client, based on knowledge of the organization they are representing. Key project management responsibilities include. (https://en.wikipedia.org/wiki/Project_manager) defining and communicating project objectives that are clear, useful and attainable. procuring the project requirements like workforce, required information, various agreements and material or technology needed to accomplish project objectives. managing the constraints of the project management triangle, which are cost, time, scope and quality.
How does Agile work? Agile divides the entire SDLC into many small iterative and incremental cycles, called sprints which are typically 1-4 weeks long. To avoid massive systems planning and comprehensive requirement collection, agile collects requirements and develops solutions in each highly collaborative development cycle - sprint. System requirements and solutions evolve in each sprint. End-users are highly involved in each sprint and systems analysts and developers rapidly respond to the requirement changes from end-users. Without end-users involvement, requirements cannot evolve and thus Agile does not work. Agile requires creating requirement and design models (e.g., UML diagrams) only if they are necessary. That is, comprehensively detailed aspects are not required to model in the analysis and design stages before coding
Agile Manifesto Agile development focuses on keeping codes simple, testing often and delivering functional bits of the application as soon as they're ready. Agile Manifesto defines a set of principles developed by Agile Alliance (https://www.agilealliance.org/) as alternative to document-driven, heavyweight software development processes (e.g., waterfall). Agile Manifesto is a formal proclamation of 4 key values and 12 principles to guide an iterative and people-centric approach to software development. (http://searchcio.techtarget.com/definition/Agile-Manifesto) The 4 key values are Individuals and interactions over processes and tools. Working software over comprehensive documentation that is, producing a requirements document is a waste of time as requirements change so quickly). but it can be problematic for the system that requires a lot of pre-delivery analysis (e.g. critical systems) or systems developed by several teams, e.g., ERP. Customer collaboration over contract negotiation. Responding to change over following a plan.
Scrum is used to manage complex systems development using iterative and incremental practices. Scrum focuses on delivering the highest business value in the shortest time. Scrum benefits the organization by Increasing productivity and reducing time Increasing the quality of the deliverables. Coping better with change (and expect the changes). Providing better estimates while spending less time creating them. Being more in control of the project schedule and state.
Characteristics of Scrum Self-organizing and team based Product progresses in a series of month-long "sprints" Requirements are captured as items in a list of "product backlog" No specific engineering practices prescribed Uses generative rules to create an agile environment for delivering projects One of the "agile processes" Iterative and incremental Value-driven (vs plan-driven in the waterfall) Frequent delivery and high production quality Inspect and adapt Scrum process is empirical (plan->do->inspect->adapt) Note: Learning and practicing Scrum usually is not an easy job. It requires efforts and time to create Scrum mindset. Scrum is actually a problem solving approach!
Managing project schedule using Gantt Chart Two major deliverable schedules: checkpoints and milestones.
Extreme programming (XP) is a software development methodology which is intended to improve software quality and responsiveness to changing customer requirements. XP is a type of agile approach. It advocates frequent "releases" in short development cycles, which is intended to improve productivity and introduce checkpoints at which new customer requirements can be adopted. In XP, programming in pairs (two persons) or doing extensive code review, unit testing of all code, avoiding programming of features until they are actually needed, a flat management structure, code simplicity and clarity, expecting changes in the customer's requirements as time passes and the problem is better understood, and frequent communication with the customer and among programmers.
Agile Manifesto (cont.) The 12 principles (https://en.wikipedia.org/wiki/Agile_software_development) Customer satisfaction by early and continuous delivery of valuable software Welcome changing requirements, even in late development Working software is delivered frequently (weeks rather than months) Close, daily cooperation between business people and developers Projects are built around motivated individuals, who should be trusted Face-to-face conversation is the best form of communication (co-location) Working software is the primary measure of progress Sustainable development, able to maintain a constant pace Continuous attention to technical excellence and good design Simplicity—the art of maximizing the amount of work not done—is essential Best architectures, requirements, and designs emerge from self-organizing teams Regularly, the team reflects on how to become more effective, and adjusts accordingly In general, Agile development refers to any development process that is aligned with the concepts of the Agile Manifesto.
Scrum Scrum is one of the most popular Agile techniques. Agile refers to an approach family which includes many different techniques. Scrum is one type of Agile. Scrum is a lightweight process framework for Agile development. A "process framework" is a particular set of practices that must be followed in order for a process to be consistent with the framework. For example, the Scrum process framework requires the use of development cycles called Sprints, the XP (Extreme Programming) process framework requires pair programming. "Lightweight" refers to that the overhead of the process is kept as small as possible, to maximize the amount of productive time available for getting useful work done.
Scrum Process (cont.) Step One: Create Product Backlog Like any project management process, Scrum starts with a vision and goal that defines the business case justification and the high-level scope of the system development. Scrum calls this as Product Backlog. Unlike the final goal and scope as the traditional project management defines, Scrum does NOT view Product Backlog as the final goal and scope. Instead, Product Backlog is expected to evolve as Scrum proceeds and learn more about the business issues being addressed and the solutions needed.
Scrum Process (cont.) Product Backlog lists all features/requirements to be implemented, that is, what functions should be implemented, what enhancements must be provided, and what bugs must be fixed in future releases. The list of features/task should be at he high-level without specific low level details. User stories can be used for this. sets priority, estimates, and current status. is a living document. includes the following items: ID defined for each item for easy references Story describing the item to handle as a user story Estimate for the effort of an item using a point system Priority determining which item(s) should be implemented first Status indicating the current status of the item not-started-yet, in progress, done
Scrum Process (cont.) Step Two: Manage Sprints The features/tasks defined in Product Backlog is implemented in many Sprint sessions. In a Sprint session, the team selects the features/tasks from the Product Backlog and complete them followed by forming a Sprint Backlog for the next Sprint. Scrum requires many Sprints. The team executes a Sprint typically in 2-4 weeks and produces a software deliverable (i.e., real working software or a software release). The deliverable should implement one or more features/tasks.
Scrum Process (cont.) Step Two: Manage Sprints (cont.) Sprint Backlog includes the Product Backlog items (i.e., features/tasks) selected to be implemented in a Spring as well as a plan for delivering the software product and realizing the Spring goal. All Sprint Backlogs have to be estimated in order to track progress and remaining efforts. The team meets daily based throughout the Sprint to coordinate the work and keep the team focused on the Sprint goals.
Scrum Process (cont.) Step Two: Manage Sprints (cont.) A Sprint Review is conducted at the end of the Sprint to assess the work completed and demonstrate the completed work. The Sprint Review identifies what went well and what did not so that the appropriate adjustments can be made when planning the next sprint. The team presents what it accomplished during the sprint, The presentation is the form of a demo of new features/tasks or underlying architecture The Sprint Review is usually informal - may not have slides, but the team should spend one or two hours to prepare for the presentation. The whole team must participate and can invite the world.
Scrum Process (cont.) Step Two: Manage Sprints (cont.) Sprint Retrospective periodically takes a look at what are working and what are, typically around 30 minutes The whole team must participate and can invite customers and stakeholders. The whole team discusses what they'd like to start doing (new features/tasks). stop doing (current features/tasks). continue doing (current features/tasks).
Scrum Team (cont.) All other members are Team Members (called "Team" in Scrum) who are domain experts, end-users, systems analysts, developers, tester. should be full-time. are self-organizing. The role of membership can be changed, for example, from Scrum Master to Team. However, the role of membership should change only between sprints.
Scrum Team (cont.) Interrelationships between the stakeholders: Product owner bridges the gap between the scrum team and the stakeholders Product owner is also connected to the business owner and keeps communicating the owner's goals with the scrum team Scrum master is connected to both the business owner and scrum team Scrum master helps in resolving issues that scrum team is facing Scrum team members amongst themselves collaborate extensively and follow a cooperative product development model Product owner communicates the business requirements to scrum master and scrum team
Scrum Team A Scrum team typically consists of 5-7 members who are domain experts, end-users, systems analysts, and developers. Three roles a team member plays: Product Owner, Scrum Master and Team. One member acts a Product Owner who has a vision for what is to be built defines the features of the product makes scope vs. schedule decisions be responsible for achieving financial goals of the project creates, prioritizes and maintains the product backlog adjusts features and priority every sprint, as needed accepts or rejects work result play a role of leadership play a liaison to the stakeholders help the Scrum Master organize sprint review meetings
Scrum Team (cont.) One member acts as Scrum Master who is responsible for enacting Scrum values and practices removes impediments coaches the team to their best possible performance helps improve team productivity in any way possible enables close cooperation across all roles and functions shields the team from external interference plan the release plan the Sprints also plays a role of leadership Note: although Scrum Master sounds like Project Manager, there is no Project Manager role defined in Scrum. Project Manager is the leader of project management. Instead of leading the team and managing the work, Scrum Master takes a support role in helping the Product Owner and team in backlog management and completion. She doesn't manage the team in the way a Project Manager does. She ensures the team follows the scrum processes in the daily stand up meeting and other ceremonies of backlog grooming, retrospectives, and demo.
User Story in Agile Use cases aim to gather as much detailed and complete requirements as possible and thus they are time consuming and costly. The philosophy of Agile development is that to work directly with end-users and avoid doing much detailed on requirement documentation. Therefore, Agile development recommends using "user stories" in which requirements are documented on index cards or sticky notes (i.e. just a line or two).
User Story in Agile (cont.) A "User Story" is a very short description of a feature written from the perspective of a user. User stories are the key requirements artifacts in Agile projects, and typically use just one short sentence. A typical user story template is "As a <role played>, I want to <goal or desire> so that <reason or benefit>." A practical example of a user story for a CRM system: "As a sales manager, I want a weekly pipeline report so that I can track the performance of my salespeople against their quota." User stories are typically written on index cards or sticky notes, and then arranged on walls to facilitate discussion.
User Story in Agile (cont.) In addition, a "User Story" also provide Acceptance Criteria that identify the features that must be present at the completion of the task. A complete user story is as follows.
User Story in Agile (cont.) Advantages of User Stories: They are short and easy to read and understand They are modular and easy to rearrange They emphasize working systems over documentation, that is, user stories are turned to systems analysts much earlier than use cases and they can be developed into codes quickly. Users can test codes and quickly refine and come up with new user stories. So doing makes iterative and incremental processes turn around very fast. They are very efficient for small, collocated teams to build systems Disadvantages of User Stories: Since user stories are very short, it is hard to document detailed functional requirements. Best used as pointers to detailed requirements If used to replace detailed requirements, they usually do not scale for large-scale or complex projects.
Agile Approach Agile is one type of system development approaches that apply the iterative and incremental model, in which systems analysis, design and development evolve and improve through collaboration between self-organizing cross-functional teams. Agile advocates adaptive planning, evolutionary development, early delivery, and continuous improvement, and it encourages rapid and flexible response to change. (https://en.wikipedia.org/wiki/Agile_software_development) Note: Agile approach includes many different techniques such as Scrum, Kanhan, XP (Extreme Programming), LSD (Lean Software Development), RAD (Rapid Application Development), etc.
Why do we need Agile? System requirements can be very complicated and dynamic with the constantly changing business environment. As a result, systems development processes become too heavyweight or cumbersome and require long cycle. In addition, it is hard to fully or accurately understand the requirements due to lack of expertise who well understand both business and technology. Therefore, it is difficult to design and develop high quality systems. Accordingly, the business community has been seeking more adapted and agile SDLC processes so that the development team can manage the cost and risks during SDLC. A low risk/cost SDLC must be agile and require end-users to be highly involved. Agile is a systems development approach that meets today's business demands on new information systems development since it is lightweight, people-based rather than plan-based, business-focused rather technology-focused, and agile rather rigid.
Why do we need Agile? (cont.) Agile benefits clients with quicker ROI, lower total cost, fast response to change, reduced risk, faster time to market, better stakeholder relationship. Agile benefits developers with team work (high productivity and low liability), a sense of accomplishment, quality work, rhythm, visible progress, faster feedbacks. Advantages of Agile Very flexible and efficient in dealing with change Frequent deliverables constantly validate the project and reduce risk Disadvantages of Agile Team members need a high level of technical and interpersonal skills Lack of structure and documentation can introduce risk factors May be subject to significant change in scope
Why do we need Agile? (cont.) In sum, the rationality behind Agile is that every system is unique and should be implemented differently. This means there is no "one size fits all" SDLC models and any SDLC approaches should be "agile" and can be tailored to best fit to the unique development processes. Consequently, Agile aims to promote a project management process that encourages frequent inspection and adaptation. a leadership philosophy that encourages teamwork, self-organization and accountability. a set of engineering best practices intended to allow for rapid delivery of high-quality software. a business approach that aligns development with customer needs and company goals.
