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)

    图来自:https://www.valueglide.com/scaled-agile-framework

    什么是 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

    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.

    Solution

    • 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

    Toolchains

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