［隨堂筆記］20141101-1109 Agile Project Management PMI - ACP (R) 認證班－敏捷式專案管理

地點：財團法人資訊工業策進會 - 台北市復興南路一段390號2樓
講師：徐柏峰

前言

原本該在暑假前就該來上課，不想周末爬山好時光被上課給奪走，硬生生拖了近2季時光，到11月份才心不甘情不願地去上課。

11月1日(六) 08:40-17:00

開場就直說，Agile Project Management 敏捷開發重點：「應用精實管理原則，帶領敏捷開發團隊，駕馭充滿變數的專案」

• Use Agile Development with Lean Management
• Mindset on Ever-change Projects.

還沒知細節時，聽了模模糊糊的；接著又說敏捷開發的態度4個重點：

• Individuals and interactions over processes and tools 個人與互動重於流程與工具
• Working product over comprehensive documentation 可用的軟體重於詳細的文件
• Customer collaboration over contract negotiation 與客戶合作重於合約協商
• Responding to change over following a plan 回應變化重於遵循計畫

看似了解同意，卻尚未了解更細部內容；接著就說明什麼樣的專案是適合用敏捷開發，那就是Value-driven (New Product Development)較為合適；而建築土木／航大的大型建案或是政府思想古板流程皆不太合適使用，而只能用傳統的Waterfall管理方法。

接著說一些Agile簡介說不一一說明，只列出一些覺得不錯的重點與想法：

Project ＆ Project Management

• A project is "a temporary endeavor undertaken to create a unique product, service, or result".
• Project Management is "to turn sponsors' resources(cost) into works with specific time frame".

另外提及敏捷有Golden Circle，思考是從Need出發，而非是傳統Waterfall 由Scope出發；

專案管理上，敏捷與傳統Waterfall不同點在於：

• 敏捷重點在於WP (Work Product/Packages)上的管理，而非是Waterfall重點於細項Task上。
• 敏捷管理專於customers/developers之間的溝通，而非傳統指派細項工作管理。Agile PMs Don't Manage Task.

Agile Approach

• Driven by value - what's valuable to customers.

• Customers have a rough idea at the start, they will gain clarity as the project proceeds.
• Project execution is a process of discovery.
• Embrace change.

Agile Risk Management

• High Risk High Value --> Low Risk High Value --> Low Risk Low Value --> High Risk Low Value.

What to do during Iteration 0?

• Assess Architectural Needs
• Obtain 3rd Party Services
• Prepare Environments & Tools
• Obtain Funding
• Finalize Team
• Start Early

What is Interation Hardening?

• Also called Release Iteration
• To make the product ready for release (=Done means Done)
• The team stops building new features, and instead spends their time on stabilizing and packaging the product.

What to do during Iteration Hardening?

• Removing accrued technical debt.
• Fixing critical and major defects.
• Finalizing integrations to other systems
• Documenting various aspects of the product, including support and user documentation.
• Significant functional, performance, load, system, integration, user acceptance, and integration testing
• Training support personnel and end users
• Drafting an Implementation Plan and/or Deployment Plan.

Scrum

• A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
• Lightweight 文件少
• Simple to understand 易了解
• Extremely difficult to master 很難掌握
• Scrum Pillars
• Transparency (Visibility) 凡事透明
• Common Language
• Common definition of 'Done'
• Inspection (Check) 定期檢查及進度管理
• Frequently validate artifacts and progress toward a goal to detect undesirable variances.
• Adaption (Change) 調整改變
• If artifacts or processes deviates from what is acceptable, an adjustment must be made.
• Scrum Stakeholders
• Product Owner (Voice of Customer) - Why, What & When
• Scrum Master
• Development Team - How & Who

• Scrum Events
• The Sprint
• Sprint Planning Meeting
• Daily Scrum
• Sprint Review
• Sprint Retrospective

• Definition of 'Done': Shared understanding of what it means for work to be complete - Defined by TEAM.

11月2日(日) 09:00-16:00

eXtreme Programming

• 5 Values
• Communication
• Most problems and errors are caused by lack of communication
• Simplicity
• Do the simplest thing that could possibly work
• Simple <> Simplistic
• Do not plan future possible reuse.
• Feedback
• Always measure the works to know how far it is from the needed features
• Courage
• The more fear we have for a project, the bigger and heavier the methodologies we need.
• Respect
• Be respectful
• to your colleagues and their contributions
• to your organization
• to people who will use product you are working.
• 12 Core Practices
• System Metaphor (Vision 願景)
• An easy to understand description that explains product design to stakeholders without resorting to dumping huge documents on them.
• Onsite Customer
• A dedicated and empowered person who determines requirements, sets priorities, answer questions and verifies what have been delivered.
• The Planning Game
• Customer defines the business value of desired features using cost estimates provided by the developers.
• Simple Design
• Less is more
• Keep It Simple and Stupid, KISS
• Coding Standards
• Rules for team members to do work in the same way
• Pair Programming
• Do all tasks in pairs, 2 developers working together at one machine.
• Collective Code
• All the work belongs to all the developers - we built it together!
• Continuous Testing
• Validate work at all times
• Write test first

• Refactoring 重構
• Restructuring an existing body of work, altering its internal structure without changing its external behavior.
• Keep work clean:
• Without duplication
• High communication
• Simple yet complete
• Continuous Integration
• Integrate and build work multiple times a day
• Pair writes up unit test cases and code for a task
• Pair unit tests code to 100%
• Pair integrates new code
• Pair runs ALL unit test cases to 100%
• 40 Hour Work Week
• Tired people make more mistakes, which slow down more in the long run
• Work smart
• Small Releases
• Implement a concept into reality early and update it frequently on a short cycle.

XP2

• new 12 Core Practices
• Sit Together New
• Develop in open space big enough for everyone
• Have small, private space nearby.

• Whole Team New
• Have a cross-functional team with the suitable number of members - Tipping Point, 7+-2 = 5~9.
• Informative Workspace New
• 
  
• Energized Work - Was "40-Hour Week"
• Pair Programming
• Stories - Was "Planning Game"
• Weekly Cycle - Was "Planning Game"
• Quarterly Cycle - Was "Small Releases"
• Slack New
• In every iteration, plan some lower-priority tasks that can be dropped if you get behind
• Ten-Minute Build New
• Automatically build the entire system and run all tests in 10 minutes
• Feedback, feedback!
• Continuous Integration
• Test-first Programming - Was "Continuous Testing"

Lean Agile

• A systematic approach to identifying and eliminating waste (non-value-added activities) through continuous improvement by flowing the product at the pull of the customer in pursuit of perfection.
• An approach to Agile Product development using Lean mindset for guidance
• Agile practices are manifestations of Lean principles.
• Optimize the Whole
• Organization - Integrating enterprise, team, and individuals to work best together
• Time - Not just now, but in the future. We want sustainable ROI from our effort.
• Product - Not just its development, but also it maintenance and integration.
• Value Stream
• Sequence of actions that flows from customer input requirements to product deployment, and along which information, materials, and value flows.
• Shortening value stream duration is one key to reducing the time to market.
• Value Stream Mapping
• A Lean tool that practitioners use to
• Analyze the value stream
• Get the root cause.
• Lean Believes
• Most errors are due to the system within which people work than to the individuals themselves
• People doing the work are the best ones to understand how to improve the system
• Ad hoc is not an acceptable process
• Looking at when things are done in a process is a more useful guide than trying to make sure that every step at the way is as efficient as possible
• Our measure for success must be related to the amount of time between when ideas come in and when they are manifested as value to our customers.
• Management must work with the team to improve the way it works to improve its own efficiency.
• Teams are most efficient when the amount of work is limited to their capacity
• Team efficiency improves by minimizing the amount of work in progress at any one time
• When evaluating actions, we must optimize the whole, not merely improved individual steps in the process
• The are principles to reduce waste
• Lean Principle
• Respect People
• It is the team not the management that has the right to define 'process'
• Process is about "how to build the thing right within constraints they are given"
• When constraints change, process is changed.
• Eliminate Waste
• 7 Forms of Waste
• Inventory
• Defects & Rework
• Over Processing
• Motion & Double handling
• Waiting & Searching
• Overproduction
• Transportation
• Defer Commitment
• Decide as late as possible. Wait until "the last responsible moment, LRM" to make a decision
• We either don't work on something until we need to or we set it up so that we can make decisions that can be reversed later when we get more information.
• Create Knowledge
• To mitigate market and technical risks
• Deliver Fast
• Deliver as soon as possible
• Deliver early and often
• Focus on adding value to the customer without delay to get
• Better market penetration
• Greater credibility
• Strong loyalty
• Earlier revenue
• Fail Fast
• Build Quality In
• Built Integrity in "Define acceptance test before developing".
• Optimize the Whole
• Fast Flex Flow
• Get an idea into the development pipeline and out to the customer as fast as possible
• Focus on Time
• Mass production looks at machine utilization. Lean focuses on time
• Just in Time
• Work only on those parts that we need to, and then only just before they are needed.

Lean Startup

• What is a Startup?
• A startup is a deliver a new product or service conditions of human institution extreme uncertainty
• Nothing to do with size of company, sector of the economy, or industry
• Startup = Experiment
• Priniciples
• Entrepreneurs are everywhere
• Entrepreneurship is management
• Validated Learning
• Build - Measure - Learn
• Innovation Accounting
• Pivot (Change)
• Change directions but stay grounded in what we've learned
• Speed wins!
• If we can reduce the time between pivots
• We can increase our odds of success
• Before we run out of money
• MVP
• Minimum Viable Product
• Helps test our assumptions while minimizing the work we put into unproven ideas.
• Prototype MVPs
• Non-prototype MVPs
• Retrospective

1. Set the Stage
• Help people focus on the meeting
• Start with brief welcome and appreciation
• Outline the meeting
• Ask everyone to speak
• NOT skipable
2. Gather Data
• Create a shared picture of what happened in the past iteration
• Start with the 'HARD' data: events, metrics, features completed...
• Visual depiction is helpful
3. Generate Insights
• Ask why and thing about what to do differently - Find the root cause. 5 Whys
4. Decide What to Do
• Pick up the top items and plan what to experiment for the next iteration
• Be sure that people sign up and commit to actions.
• S: Specific
• M: Measurable
• A: Achievable
• R: Realistic
• T: Time-bound
5. Close the Retrospective
• Decide how to document the experience and plan for follow up. (生活公約）

Agile in a Flash

• Values & Practices
• A set of values that leave it to the practitioners to decide how to apply them
• A set of practices that are suggested to manifest good results

Agile Manifesto 敏捷宣言

• Individuals and interactions over processes and tools 個人與互動重於流程與工具
• Working product over comprehensive documentation  可用的軟體重於詳細的文件
• Customer collaboration over contract negotiation 與客戶合作重於合約協商
• Responding to change over following a plan 回應變化重於遵循計畫

Agile Principles

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (product).
2. Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
3. Deliver working software (product) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the project.
5. Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
7. Working software (product) is the primary measure of progress.
8. Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
9. Continuous attention to technical excellence and good design enhances agility.
10. Simplicity - the art of maximizing the amount of work not done - is essential. (anti-gold-plating) KISS: Keep It Simple and Stupid!
11. The best architectures, requirements, and designs emerge from self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Agile Mindset

• Barely Sufficient
• Just Enough!
• Minimize the time spent on anything that doesn't actually form part of the end product.
• Less Is More
• Deliver the minimum necessary to meet the business goal within business constraints.
• Fail Fast
• Get bad news early either to avoid wasting more money or gain more time to mitigate the impact.
• Just in Time
• Invest the time to implement a feature only when we know for sure we'll need it.
• Time Box & Velocity
• Time Box
• Segment of time with a defined start and end; often refers to an "iteration."
• Velocity
• How "fast" can team deliver within a time box?

11月8日(六) 09:00-17:00

The Essence of a User Story

專案開頭先談Who (人），不同關係人(stakeholders)，其需求也有所不同

Who ＝C P U
針對最近的食安事件，進行 "食安APP" 軟體開發。
C (Chicken) : Manager, Stakeholders
P (Pig) : Devs, QA, PO (BA), UX, UI, Agile PM
U (Users) : 主婦、上班族、小吃店、餐廳、食品廠、政府、藥局、診所。

用3個人物角色(Boss, 貴婦, 雞妹)，來說明不同的User Story；
紅卡是針對食安議題缺失或弱點的User Story
綠卡反之，而是對此議題有正面方法的User Story
黃卡則是紅／綠卡的建議解決方案。

而食安議題APP的Vision在套用功式的結果，如下：

針對  貴婦、小吃店  客戶群，有  買的安心／用的便宜  的需求下，除了  列出問題產品  以外，還有可用  照妖鏡、團購、比價  等功能。

• Why (Vision)
• Every stakeholder has a different need
• Formal requirement document tend to become a goal itself
• As customers see what have been working, they come up with new ideas.
• We need to make information sharing and decision making effective.
• What (Project: Cost, Scope, Time)
• A user story is a short description of user-valued or customer-valued function.
• Use stories are composed of 3 aspects
• Card: For planning and as a reminder
• Example: As a librarian, I want to be search for books by publication year, so that....
• Conversation: To flesh out details
• Confirmation: To determine when a story has been completed.
• How to Demo / Acceptance Criteria
• How (Management)
• How is a user story formatted?
• Front
• General version: As an estimator, I want to see the item we're estimating so that I know what I'm giving an estimate for
• Shorter version: As an estimator, I want to see the item we're estimating
• Even shorter version: An estimator can see the item he / she is estimating
• Back
• Acceptance Criteria Conditions against "SMART" criteria.
• Who (Needs) - Ensure there is only one customer voice!!!
• The customer should write user stories, because:-
• Each story must be written in business language, not in technical jargon.
• As the primary product visionaries, the custom is in the best position to describe the product behavior.
• If getting a single person as the customer is too much hope for, the customer team consisting of a product manager, BA, QA, Dev Lead, interaction designer and real users can be established instead.
• When - Acceptance Criteria (AC)
• The customer is allowed to write a user story any time, but
• The acceptance tests must be written before developing begins
• All acceptance tests must be executed at the end of each iteration.

Types of Benefits

• New Revenue 新收益
• Whoever is requesting the theme should be able to quantify the reasons for building it
• It's difficult to get solid data
• Sales projections would be helpful
• New customer
• Incremental Revenue 增加收益
• Additional revenue we can get from existing customers. A product brings forth additional revenue because it:
• Encourages existing customers to purchase more licenses
• Includes optional, add-on modules that can be sold separately
• Includes features that allow charging a higher price
• Encourages the use of consulting services (e.g. to integrate with a separate third party application).
• Retained Revenue 續保收益
• The revenue an organization will lose if the project is not performed.
• It's what an organization will no longer lose
• Operation Efficiencies 效能改善
• Anything that takes a long time or that would take a long time if the company grew
• Better integration or communication between departments
• Reduced employee turnover
• Shorter training time for new employees
• Any time-sensitive process
• Combining multiple processes
• Anything that improves accuracy and reduces rework

INVEST in User Stories

A valid user story is:-

• Independent 獨立
• Avoid dependencies between stories
• Negotiable 可談
• Avoid details because they will be worked out through conversation
• Valuable to Purchasers or Users 對採買人及使用者有用
• Avoid stories only value by developers
• "All connections to the database are conducted through a connection pool"
• "All error-handling is done through a set of classes"
• The best way is to have customer write the stories. 請PO或BA來寫，而非是Developer來寫
• Estimable 可測／評估
• Avoid stories whose sizes are inestimable 
• The reasons why developers are not able to estimate a story
• The lack of domain knowledge
• The lack of technical knowledge
• The size of the story (being too big)
• Way to make an inestimable story estimable
• Spike 針對技術證明其可行性
• Have an experiment to learn about it in one iteration (time-boxed)
• Re-estimated it in subsequent iterations
• Split 切割
• Disaggregate it into smaller, constituent stories.
• Small
• Testable