地點：財團法人資訊工業策進會 - 台北市復興南路一段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
- Set the Stage
- Help people focus on the meeting
- Start with brief welcome and appreciation
- Outline the meeting
- Ask everyone to speak
- NOT skipable
- 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
- Generate Insights
- Ask why and thing about what to do differently - Find the root cause. 5 Whys
- 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
- 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
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software (product).
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
- Deliver working software (product) frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people and developers must work together daily throughout the project.
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
- Working software (product) is the primary measure of progress.
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good design enhances agility.
- Simplicity - the art of maximizing the amount of work not done - is essential. (anti-gold-plating) KISS: Keep It Simple and Stupid!
- The best architectures, requirements, and designs emerge from self-organizing teams.
- 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
