Buzzwords 串烧

    Linear inspired Issue Tracking System

    [Google Issue Tracker] Why build yet another issue-tracking tool

    • An issue tracker is an application that users and developers use to maintain a database of software defects, change requests, technical-support requests, development tasks, and other issues that the project members must work to resolve. Since they’re so central to each developer’s daily work, many issue tracking systems have already been built.
    • Most existing issue tracker tools force developers to follow a particular software development process by defining a set of fields, possible values, and workflow states for each issue.
    • The result is often a complex tool that’s difficult to use because it includes many fields and options that aren’t applicable to a given issue. In contrast, our issue tracker uses only a minimal set of fields, and offers users the ability to store the information that they need as labels. This approach is possible because it uses Google’s free-text search technology to search on all issue metadata.

    Scaled agile framework (SAFe)


    什么是 SAFe ( Wikipedia )

    • The SAFe is a set of organization and workflow patterns intended to guide enterprises in agile practices. SAFe is one of a growing number of frameworks that seek to address the problems encountered when scaling beyond a single team.
    • SAFe promotes alignment, collaboration, and delivery across large numbers of agile teams.
    • The primary reference for the SAFe was originally the development of a big picture view of how work flowed from Product Management through governance, program, and development teams, out to customers.
    • SFAe has also received criticism for being too hierarchical and inflexible.

    SFAe challenges

    • Coping with longer planning horizons: typically development teams refine their backlog up to 2-3 iterations ahead, but in larger org the product marketing team needs to plan further ahead. Often we should work with a very high level, 12-18m roadmap, then plan collaboratively with the teams for 3m of work. The dev teams still get into detailed refinement 2-3 iterations ahead, only getting into detailed task plans for the next iteration.
    • Dealing with delegated authority: In Scrum, the Product Owner is expected to assume responsibility for the full product life-cycle, including the ROI (return on investment) of dev decisions, as well as performance in market. On large-scale developments, the org wants a view across multi-team backlogs, such as provided by a PM (Product Manager).
    • Synchronizing deliverables: Agile frameworks are designed to enable the dev team to be autonomous and free to design how they work. SAFe acknowledges that, at the scale of many tens or hundreds of dev teams, it becomes increasingly chaotic for teams to fully self-organize. It therefore puts some constraints on this, so that where teams are working on the same product, theirs deliverables can be better sync for releasing together

    SAFe Principles

    1. Take an economic view
    2. Apply system thinking
    3. Assume variability; preserve options
    4. Build incrementally with fast integrated learning cycles
    5. Base milestones on objective evaluation of working systems
    6. Visualize and limit WIP, reduce batch sizes, and manage queue lengths
    7. Apply cadence (timing), sync with cross-domain planning
    8. Unlock the intrinsic motivation of knowledge workers
    9. Decentralize decision-making
    10. Organize around value

    Jira Align

    Jira Align ( a separately managed solution that is cloud-based ) connects business strategy to customer outcomes at enterprise scale. It helps:

    1. Make work visible at enterprise scale (cross-project visibility)
    2. Gets all teams aligned across an enterprise (Supports Scrum, Kanban, and blended team-level agile methods)
    3. Maximizes outcomes, driving value and accelerating digital strategy


    • Jira: Epics / Fix Versions / Sprints / Stories / Projects & Boards / Users
    • Jira Align: Mission, Vision, Values / Strategies / Goals / Themes / Epics / Capabilities; Features / Release Vehicles / Sync Sprints; Programs / Stories / Teams / Users

    Key Points:

    • Are teams aligned with our business goals?
    • Should we continue to invest in this initiative?
    • Which initiatives are at risk?
    • What roadblocks are we likely to encounter?
    • Are we going to deliver on time and budget?

    Demystify Scrum terms

    摘自文章 Sorry Scrum, the Game Might Be Over for You!

    … I’ve observed many powerless Scrum Teams because the environment was dysfunctional. The most common dysfunctions are:

    • Lack of trust
    • Lack of direction
    • Prioritization based on title
    • Micro-management

    Successful use of Scrum depends on people becoming more proficient in living 5 values: Commitment, Focus, Openness, Respect, and Courage. To success with Scrum, organizations have to go through a massive transformation. However, top management believed it is too risky to have truly self-managing teams. This is why Scrum hits a glass ceiling.

    Different paradigms in business:

    • Empowerment vs. micro-management (giving directions vs. giving instructions)
    • Outcome vs. output
    • Alignment vs. consensus
    • Take risks vs. follow a plan

    SAFe 一个实践

    Lily 之前的一个分享:
    … Deliver out-of-box solution of micro-services based product suites running on top of k8s on premise, public cloud or SaaS to customers and partners.


    • Single Solution: Some value streams can be realized by a single ART (Agiled Release Train)
    • Large Solution: Larger value streams require multi-ARTs


    • ART consists of: DevTeam + ScrumMaster + Product Owner → Plan together → Integrate and demo together → { sync dev } → Deploy and release together → Learn together


    • Inspect & Adapt
    • Daily Stand-up / Iteration planning / Iteration Retro / Iteration Review / Backlog refinement


    • Product Manger:
      • Market/Customer facing. Identifies market needs. Collocated with marketing / business.
      • Owns vision and roadmaps, program backlog, pricing, licensing, ROI
      • Drives PI objectives and release content via prioritized features and enablers
      • Establishes feature acceptance criteria
    • Product Owner:
      • Solution, technology, and team facing. Collocated with teams
      • Contributes to vision and program backlog. Owns team backlog and implementation
      • Defines iterations and stories. Accepts iteration increments
      • Drives iteration goals and iteration content via prioritized stories
      • Establishes story acceptance criteria, accepts stories into the baseline
    • Team:
      • Customer / stakeholder facing.
      • Owns story estimates and implementation of value.
      • Contributes to intentional architecture. Owns emergent design.
      • Contributes to backlog refinement and creation of stories.
      • Integrates with other teams


    • Day1 Agenda
      • Business context
      • Product / Solution vision
      • Architecture Vision & Development Pratices
      • Planning Context & Lunch
      • Team Breakouts
      • Draft Plan Review
      • Management review & Problem solving
    • Day2 Agenda
      • Planning Adjustments
      • Team Breakouts
      • Final Plan Review & Lunch
      • Program Risks
      • Confidence Vote
      • Plan Rework?
      • Planning Retrospective & Moving Forward


    • Continuous Planning and Collaboration
    • Configuration Management
    • Continuous Integration
    • Continuous Testing
    • Continuous Delivery & Deployment
    • Continuous Improvement

    Engineering Productivity

    Measuring software development productivity

    Engineering Productivity is often seen as delivering functionality at a lower cost. Hence any measure MUST take into account all of these factors:

    • Speed
    • Effort/Cost
    • Volume of Functionality Delivered
    • Quality: less defects / usability


    • Velocity is a measure of the amount of work a Team can tackle during a single Sprint and is the key metric in Scrum. Velocity is calculated at the end of the Sprint by totalling the Points for all fully completed User Stories.
    • Velocity is a key feedback mechanism for the Team. It also facilitates very accurate forecasting of how many stories a Team can do in a Sprint. Without Velocity, Release Planning is impossible. By knowing Velocity, a Product Owner can figure out how many Sprints it will take the Team to achieve a desired level of functionality that can then be shipped.
    • Measuring velocity is sometimes called velocity tracking. The velocity metric is used for planning sprints and measuring team performance