Wydawca: Andy Webb Kategoria: Edukacja Język: angielski Rok wydania: 2015

Agile Project Management Methodology for Beginners: Scrum Project Management for Beginners ebook

Andy Webb  

(0)

Uzyskaj dostęp do tej
i ponad 25000 książek
od 6,99 zł miesięcznie.

Wypróbuj przez
7 dni za darmo

Ebooka przeczytasz w aplikacjach Legimi na:

e-czytniku kup za 1 zł
tablecie  
smartfonie  
komputerze  
Czytaj w chmurze®
w aplikacjach Legimi.
Dlaczego warto?
Czytaj i słuchaj w chmurze®
w aplikacjach Legimi.
Dlaczego warto?
Liczba stron: 65

Odsłuch ebooka (TTS) dostępny w abonamencie „ebooki+audiobooki bez limitu” w aplikacji Legimi na:

Androida
iOS
Czytaj i słuchaj w chmurze®
w aplikacjach Legimi.
Dlaczego warto?

Ebooka przeczytasz na:

e-czytniku EPUB kup za 1 zł
tablecie EPUB
smartfonie EPUB
komputerze EPUB
Czytaj w chmurze®
w aplikacjach Legimi.
Dlaczego warto?
Czytaj i słuchaj w chmurze®
w aplikacjach Legimi.
Dlaczego warto?

Pobierz fragment dostosowany na:

Zabezpieczenie: watermark

Opis ebooka Agile Project Management Methodology for Beginners: Scrum Project Management for Beginners - Andy Webb

The older rigid traditional models of delivering changes has been replaced with an agile way of delivering changes. The world of apps, and internet driven economy means that any change has to be delivered almost overnight with no scope for delays and the consumer wants things almost immediately.Agile provides that project management methodology to help you get the results immediately.

Opinie o ebooku Agile Project Management Methodology for Beginners: Scrum Project Management for Beginners - Andy Webb

Fragment ebooka Agile Project Management Methodology for Beginners: Scrum Project Management for Beginners - Andy Webb

Andy Webb

UUID: baf4b91a-59be-11e5-b167-119a1b5d0361
This ebook was created with StreetLib Write (http://write.streetlib.com)by Simplicissimus Book Farm

Table of contents

Agile Project Management Methodology for Beginners: Scrum project management for beginners

Dedication:

CONTENTS

INTRODUCTION

CHAPTER 1

CHAPTER 2

CHAPTER 3

CHAPTER 4

CHAPTER 5

APPENDIX

Free Gift and Thank You

by Andy Webb

Text Copyright © 2015 Andy Webb

All Rights Reserved

Smashwords Edition

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.

*****

Dedication:

To my parents.

*****

Agile Project Management Methodology for Beginners

Scrum project management for beginners

By Andy Webb

http://thetruemanager.com/freegift

*****

CONTENTS

*****

Introduction

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

*****

INTRODUCTION

*****

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

*****

CHAPTER 1

AGILE OVERVIEW

*****

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.

Source: http://agilemanifesto.org

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