Ebooka przeczytasz w aplikacjach Legimi na:
Odsłuch ebooka (TTS) dostępny w abonamencie „ebooki+audiobooki bez limitu” w aplikacji Legimi na:
Agile Project Management Methodology for Beginners: Scrum project management for beginners
Free Gift and Thank You
by Andy Webb
Text Copyright © 2015 Andy Webb
All Rights Reserved
Disclaimer: This book contains general information that is based on author’s own knowledge and experiences. It is published for general reference and is not intended to be a substitute for professional advice. The publisher and the author disclaim any personal liability, either directly or indirectly, for the information contained within. Although the author and the publisher have made every effort to ensure the accuracy and completeness of the information contained within, we assume no responsibility for errors, inaccuracies, omissions and inconsistencies.
To my parents.
By Andy Webb
1. Agile Overview
2. Agile Up Close
3. Introduction to Scrum
4. Scrum Up Close: The Sprint Cycle
5. Agile in Action
Appendix: The 12 Principles of Agile
Free Gift and Thank You
My first experience with Agile was in 2005 at a small tech startup company on the West Coast. At the time, the concept of software as a service (SaaS) was in its infancy, and we ended up developing a great product that fell short of its potential because the public was still committed to desktop software.
But the seed had been planted, and I’ve spent my entire career since then working as a contractor in small startups developing software products. With the emergence of cloud computing in 2008, a lot of pieces fell into place for me. Since then I’ve been part of several great projects, including a number of mobile web applications. Invariably, the most successful companies I’ve worked for used Agile to manage their teams.
My intent in writing this book is to use my experience as an Agile team member to introduce readers to the basic principles of Agile. This is not an advanced Agile practice manual. In fact, I believe that once you learn the basics, the best place to learn advanced Agile methods is on the job. My role is to explain its basic concepts and lay out how the various parts of Agile fit together as a whole system in the real world of project management.
The book’s primary focus is on the Scrum variant of Agile because Scrum is the best known and most widely used of the Agile methodologies. In its original form, it predates Agile itself and served as inspiration for Agile’s principles. For this reason, I made a conscious decision to use Scrum as a lens through which the reader can view Agile in practice. Readers should know that Scrum isn’t the only form of Agile, or even the best one for all projects. It’s simply the best vantage point (in my opinion) for understanding Agile, and lightweight software development methods in general.
Agile is a powerful tool for fostering teamwork and mutual support, but only when all of the team members share the same understanding of how it works. Agile is great for defining roles and generating problem solving strategies, but it can also serve as a source of inspiration and camaraderie. This is especially critical in a startup environment, where the pressure can be tremendous.
The principles of Agile are so powerful that they extend far beyond the software development world. It was my intent in writing this book to present the underlying structure of Agile in simple enough form that you, the reader, can pick it up and apply it to tasks as diverse as managing a non-tech company, building a house, mastering a new skill or hobby, or living a more productive and meaningful life.
I hope this book lays the foundation for you to put the Agile method into practice as you strive for the goals you want to reach, and that it becomes a permanent part of your life toolkit.
– Andy Webb
What Is Agile?
Agile is a lightweight software development method that aims to be more efficient than traditional, plan-driven development models. Agile seeks to do more with less:
- more team-level decision making
- faster development time
- faster response to shifting customer demands
- faster problem solving
- more customer satisfaction
- smaller teams
- less expense
- less wasted effort
- fewer features in the end product that either don’t work or are never used
As a contractor on several development teams in the early 2000s, I experienced firsthand the inefficiencies of plan-driven methods for developing software. I confess my guilt as an aider and abettor in developing numerous examples of what came to be known as “bloatware.” These programs often took three or more years to develop, yet their customer satisfaction levels were poor. After working on Agile teams for a few years, I came to understand why those massive projects of the past so often turned into massive failures. Here is a summary of the mistaken assumptions that led to the proliferation of bloatware.
Full-Featured Is Always Best: before Agile, there was a widespread dogma that good customer service always meant developing software with hundreds of features to address each and every perceived customer need, large or small, as if they were of equal importance. In reality, full-featured software was a limited market, and customers were hungry for simple programs that were easy to learn and would solve their specific problem.
Belief in Static Customer Expectations: another issue was the belief that customer demand could be captured in snapshot form and would conveniently remain unchanged while the development team did its thing. This might have been true before the internet, but as soon as consumers started using the web, customer demand for features began to shift on a daily basis. The old development models were aiming for a target that had long since ceased to exist.
Long Product Development Cycles: predictive (plan-driven) development models dictated that a program couldn’t be released until all of its features were finished and bug-free. The desire to release quality products is admirable, but the size and scope of those products meant they would be obsolete long before their release date.
The Agile methodology was a reaction – or maybe rebellion is a better word – against these dogmas. As a veteran Agile team member, I want to emphasize that this wasn’t merely an attempted power grab by coders who didn’t like authority. So-called “cowboy coding,” where there’s no supervision and team members just go off and do whatever strikes their fancy on that day, doesn’t make sense from a business perspective. The point of the Agile movement is that the old, micromanaged development model doesn’t make good business sense either. The real focus of Agile is to once again put the customer’s needs at front and center, where they belong.
The Agile Manifesto
Lightweight development methods such as Scrum had been in use since the mid-1990s but were known by few people other than the teams that were using them. Agile became a movement in February 2001, at a meeting at the Snowbird Resort in Utah. There, 17 software developers got together and refined the underlying principles of lightweight methodology into the Agile Manifesto.
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
The original drafters of the Manifesto wrote 12 Principles of Agile soon afterward. These principles grew out of the Manifesto and were written to provide more specific guidance to teams that wanted to use Agile for software development. The 12 Principles are listed in the Appendix of this book.
The goal of the Manifesto is to reintroduce empirical principles to software development. I say “reintroduce” because in the early days of coding, before software became a multibillion dollar industry, empirical development was the norm: that is, it was assumed that the realities of the actual project should guide the direction of the project. Blind obedience to the plan, even when the plan was wrong, came later, when mammoth budgets and gigantic teams seemed to require a book-length master plan laid out in advance.
A Look at Traditional Software Design Methodologies