Blueprints are the key mean to establish oeprational execution plans and to track and communicate delivery of them. Every engineer should feel comfortable to use these to document and plan all engineering work that isn't captured through bugs.
Blueprints always cover a tangible deliverable that can be achieved in less than a month time. For efforts that span more than that time, we make an agile plan that breaks up the effort in one or many blueprints.
The characteristic of "agile" means that for multi month projects we think about a high level roadmap that will deliver the feature. The high level roadmap defines very high level steps that each would be less than one month of work and each step would yield a tangible deliverable.
Tangible deliverable can be anything tangible: deployed feature, code, a documented plan/paper, a summary of research in the wiki, a mail thread, etc. be innovative, but always wrap up your work into something tangible early and often!
Agile means that we don't plan out the detailed engineering work for all the steps, but just for the current and next work that is being done. In this way we keep the investment on things in the future low, allowing us to accomodate the plan based on new findings or previously unsharp requirements without much waste.
- Define the Wider Context oft the blueprint
- Define the Problem it aims at
- Define the deliverable this blueprint shoots for and point out any dependencies and known followups to solve the problem
- Define the approach taken on a high level; this is usually used to derive the acceptance criteria
- Define where the code will be delivered to (e.g. bzr/git branch) and if and where the feature will be deployed
- Ensure that a PM can validate the delivery using the info in the acceptance criteria.
- be sure you always link to a roadmap card that covers the wider effort of your work. If you don't know which roadmap card you are working against, speak to your lead.
- use these to plan the individual steps
- include validation steps
- be concrete and break down work items that don't convey what exactly will be done
- use this to sort your mind and get a TODO list
- once a blueprint has been accepted, the work item list will remain static. Any changes to it must be approved by the tech lead.
Blueprint undergoes a few stages:
Background: Ideas and requests come in all the time; it's important to systematically capture and record them; we use blueprints to incubate them.
Trigger: Feature Request/Idea gets raised/submitted.
Input: Management, Engineer, Stakeholders are entitled to bring up feature requests and new ideas with the TL/PM/engineer
Output: Blueprint stub that captures the idea/request and documents the initial input given by the stakeholder as well as who that is
Goals: human readable title as well as a Description capturing the context, initial priority suggestion
Background: Feature Requests and Ideas incubation has to gather requirements from the stakeholdesrs and do up front investigation to clear the path for something drafting the details.
Trigger: PM/TL approves the blueprint for the engineering/trunk series, sets blueprint to Discussion state and assigns Drafter
Input: A blueprint in "Dicussion" state with a "Drafter" assigned
Output: A blueprint with complete description as well as headline and acceptance criteria that sum up the requirements for the feature/idea
Goals: establish the tangible deliverable, it's scope and it's high level requirements
Drafting: During this phase the engineer usually works with Linaro teams to come up with an execution plan, and concrete work items that will deliver the acceptance critieria and ensure validation of the delivery. A technical manager should be able to understand if and how the work items steps will deliver the acceptence criteria. This phase is usually initiated once it becomes clear that the feature will be approved for engineering soon. The work items list at this point is not static and can undergo changes. The goal is to have the blueprint in a Ready-To-Code state.
Engineering: Once the blueprint is ready to code, the PM/TL target the blueprint against the appropriate milestone; from there on engineering (can) start and blockage/delay should be escalated through whiteboard comment as well as using the BLOCKED state for the individual work items. Any changes that are required for work items must be approved by the technical lead of the team.
Delivery: Once code is ready, and merged mainline, validation of the acceptance criteria as well as a potential sign off plan agreed with the QA services team needs to be done. PM checks the acceptance criteria and decides whether the blueprint can be marked as "implemented" or if further actions are required. This stage also takes a higher level view to evaluate if any follow up work is required to solve the greater problem the blueprint tries to address and creates new blueprints accordingly. In case of multi blueprint effort, the next steps are also decided and drafting state entered (or the agile plan tweaked)
Release: RM/PM communicate delivery of blueprints as part of the monthly release.
Platform/Guidelines/Blueprints (last modified 2013-01-30 08:22:29)