Agile Development Method - Lean Development
2025-02-10 15:36:00 0 Report
Login to view full content
Other creations by the author
Outline/Content
Principle
Explore and discover valuable insights
Explore
Uncertainty
Admit one's ignorance
Explore the accurate target audience
Discovery
Essential issue?
How to establish effective channels?
What kind of solution is it?
How can we get them to pay?
How to establish a reasonable cost and revenue model?
How to design the interaction process (scenario)
Focus on and enhance the efficiency of value flow.
Focus
Focus on flow efficiency, rather than resource efficiency.
Enhancement
Leverage collaboration between organizations to enhance organizational performance (quality, efficiency, measurability).
Engineering Practice
Automated Acceptance Testing
Test-Driven Development
Continuous Integration
Continuous Refactoring
Domain-Driven Design
Service Architecture
Deploy the pipeline
Automated Operations and Maintenance
Operation and maintenance as well as business data monitoring
Objective
Smooth: Refers to the value delivery process being seamless, completing the delivery of user value in the shortest time possible, rather than sporadically with constant issues.
High quality: meeting requirements, avoiding unnecessary errors, and engaging in necessary trial and error for exploration are not conflicting.
Valuable Outcome: The delivered value should meet market and user requirements and generate business impact, promoting organizational performance.
Management Practices
Lean Startup, Innovative Practice
Business Model Design
Verification step planning
Lean Product Design
Qualitative verification
Lean Analytics
Impact Map
Lean Requirements Analysis and Management
Scene Analysis
Test case design
Domain Modeling
Requirement Map
Release Planning
Instantiating requirements
Lean Kanban Methodology
Visualize the flow of value
Visualization of User Value
The end-to-end flow process of user value
User value flow issues and blockages
Materialize process rules
Flow rules
Collaboration Rules
Control the quantity of work in progress.
Help the team expose bottleneck issues.
Postpone the start, focus on completion.
Control the water and attack the sand.
Lake Rock Effect
Manage the flow of work
Requirement Pool Management
Readiness (Commitment) Meeting
Standard
The requirements are clear enough and will not change in principle.
The ability to analyze product requirements
Examine the capability to uncover product requirements
Examine the planning ability for product requirements
The requirements have been clarified to the development team and understood consistently.
Examine the instantiation capability of product requirements
Evaluate the user story writing ability
Evaluate the ability to decompose product requirements
The communication skills required to assess product requirements
Examine the product coordination and organizational capabilities.
The development team promises to complete the task as soon as possible.
Principle
The dangers of a too slow rhythm
Lower the perceived quality, lack of sufficient business information
Causes scope creep, which may be useful or arise from the demand plan, leading to many speculative requirements.
Does not support effective learning and innovation well, feedback after delivery is slow or even left unresolved.
Reducing the team's ability to respond flexibly to market changes, filling in many requirements at once, and having to wait for the next round of filling when changes occur.
Lower the focus on requirement clarification and the team, and it takes a long time to get started after the requirements are ready, making it difficult to ensure the effectiveness of the clarification.
High rhythm brings additional costs.
All relevant personnel need to prepare, as there are high coordination costs.
The higher the uncertainty in the market, technology, and development, the more frequently the queue needs to be refilled.
Select an appropriate number of requirements that meet the criteria.
Select high-priority requirements
Clarify requirements
Define acceptance criteria
When the demand is too large, it needs to be split.
Evaluate the technical risks of the requirements
Confirm related parties
Secondary Queue
The frequency of external information changes is low, and the demand pool is updated over a long cycle.
High internal frequency
Plan
Ready
Kanban Meeting
Prepare
Every day
Fixed time
Before the Kanban
The Kanban has been updated in advance.
Principle
Inspect from right to left
Pull from right to left
Follow
Bottleneck, the queue of backlogged itineraries
Interruption, insufficient input in a certain link
Demands that require special attention, involving significant commercial interests or risks
Demands that are hindered due to dependency (external or internal) cannot proceed normally.
Demands that are about to or have already expired, which have not been fulfilled in the commitment.
Demands with long-term lack of progress, extended periods of time spent.
Release Review
Establish feedback and continuously improve.
Little's Law
Average Delivery Week: The time from when a requirement enters the development team to when it is completed and delivered to the market.
Number of parallel requirements: The total number of parallel requirements in the entire system, which is the sum of the requirement documents at various stages.
Average delivery rate: refers to the number of requirements delivered per unit of time.
Obstacle Cause Distribution Matrix Chart
Y-axis: Cause Classification
The requirements are not clear.
Design
Third-party dependencies
Supplier
Tools, R&D
Other
Horizontal axis
The time required from the occurrence of an obstacle to its removal.
Lead Time Control Scatter Plot
Y-axis: Time taken from demand readiness to delivery
X-axis: Delivery Date
Control line: within 1-3 standard deviations
Quality Feedback Graph
Y-axis: System Modules
X-axis: Defect Classification
Cumulative Flow Diagram
Collect
Collect
Collect
0 Comments
Next page
Recommended for you
More
