Hide Notes 

Slide 1: Blueprint Agile Introduction Blueprint agile is a development framework for best development practice based on agile principles but balanced with traditional process, team, design, and documentation management. Blueprint Agile represents a development process as the improving and delivering two end results: the ever finalizing product requirements and design, and the ever improving working software. Managing the process of improving the design and requirements is as important as managing the implementation process. As a result Blueprint agile achieves the implementation in agile way and achieve the process and documentation management the more traditional way of design and process control help to improve development quality. Blueprint Agile is created by Dr. Tieren Zhou, CEO and Chief Software Architect of TechExcel, a global leading Application Lifecycle management company. Dr. Zhou specializes in conceptual modeling and knowledge centric ALM solutions research. In Dr. Zhou’s vision, future software development will be mainly managed as iterative processes for both the software design and implementation. Within each iteration, each iterative cycles will be managed as repeatable processes where software design and implementations progress parallel and yet dynamically follow a pattern of design driving implementation and working software help improving software design. What is Blueprint Agile? Blueprint agile consists of three corner stones for best development practices:    Iterative development and early delivery of working software is the best way to assure best communications between customers, product owners, and developers. Customer requirements and product design can be quantified and should be always used to drive implementation and testing Team management and process management is important to ensure lasting and effective teamwork In Blueprint, product functions are quantified to represent customer valued requirements and features. The term “Conceptual product” represents the dynamic and ever evolving requirements and features in a easy to understand product features and product functional map format. For each development iteration, there are two outcomes, the improved working software as well and the improved product design. While most of time product requirements and design are finalized and then assigned to development teams to deliver the improved working software, often the working software, which should be built on daily bases, in return help product owner and design teams to improve product functional design, and further improve the software. The quantified product requirement and functional design is represented as the “Conceptual product”. Therefore, in Blueprint Agile, a development process are divided into development iterations, and within an iteration, the “conceptual product” is used to drive implementations and QA testing, and also within an iteration, the “conceptual product” is improved and altered based on the improved working software. A development process can be summarized as the process of ever improving the understanding of the requirements, and the improving of the product design, and the incremental delivery of the working software to its final acceptance and release. 1
Slide 2: {Draw the picture to illustrate this} Why Blueprint Agile? Software development is becoming more distributed where business analysis and product design is done one country, and implemented by the outsourced teams or remote teams in other countries or other sites. Blueprint agile is based on the following fundamental observation, if business people can clearly specify and graphically describe what need to be done, developers can more effectively develop such software. Customer requirements and business logic can be and should be effectively illustrated and quantitatively represented to forms a “conceptual product”. Such “conceptual product” is ever evolving and improving just like the working software being implemented. A better development process is to incrementally build and develop both the “conceptual product” and the “working software”. Better process coordination between the business team and the development team can therefore be accomplished by enabling the business team to deliver the “conceptual product” and the development team to develop the working software based on the “conceptual product”. Such development is more disciplined and better documented by the “conceptual product” as a living system, and it is also more agile because requirement change can be more effectively communicated at the conceptual level in addition to the working software as the primary reference for achieving better understanding and communications between customers, business people, and developers. Components of Blueprint Agile Framework In the remaining of this article, we will discuss each of the following Blueprint Agile components: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. The Blueprint Agile principles Guideline for making modifications to Blueprint Agile principles The team and the job roles The conceptual product model: quantify the requirements and design The project model, quantifying the requirement so requirement can drive implementation and testing Process and workflow control for Blueprint Agile Discuss the main activity and meetings, Managing a development iteration The integrated development and QA testing model How Blueprint Agile frame work support. Agile methods 11.Blueprint Agile modeling for CRUM, XP, and FDD 12.Blueprint Agile Training and Certifications Blueprint Agile Principles Blueprint Agile is created in accordance of the Agile development principles. Because Blueprint agile emphasizes both the working software as well as the easy to understand “conceptual product” as the deliverable for coordinating teamwork and to better communicate with customers, the following agile principles are enhanced 2
Slide 3:        Deliver working software early along with conceptual product design Welcome requirement change, and react to requirement change with built in control at the conceptual product level, requirement change implies conceptual product change, and through the quantified requirement and conceptual product change, change is better documented, understood, and better documented, Scalable agile development is accomplished through people, interactions, process control, and the usage workflow/team work collaboration tools. Business people and developers must work daily throughout the project, the business people’s primary job is to work with developers to define and specify the “conceptual product”, the developer’s job is to primary to develop the “actual product”. While face to face communications is most effective, documenting the “conceptual product” helps to better communicate customer requirements and business logic, and help to facility communications with remote teams and with different culture and with different native language. While self organizing often enable developers to achieve best productivity and creativity, process control and effective managed workflow and teamwork helps such productivity and creativity, and may be essential for multi- sites and multi culture teams. Blueprint Agile Team and Job Roles Blueprint team consists of the following primary job roles:       Project manager Product owner Chief Architect (optional), Development managers Development teams (with multiple roles such as group leader, tech lead, programmer, and QA engineers) Domain experts Blueprint Agile Education and Certifications Blueprint Master: Take the certification course work required prior product manager and/or project manager experience, Blueprint Grand Master: Certification courses and 3 years of real project experience as Blueprint project manager or Blueprint Product Owner Blueprint Trainer: Train and issue certificate, Blueprint Coach:  To become Blueprint Coach, two years of project experience with Blueprint Enabled agile development, 3
Slide 4:  To renew Blueprint Coach status: Blueprint Trainer:   To become Blueprint Trainer, two years of project experience with Blueprint Enabled agile development, To renew Blueprint Coach status: Six key roles Role Project Manager FDD Responsibility Responsible to organize make the domain team and development team to work together Responsible to demo the ROI to upper management, Coach the team to follow Blueprint principles, DevSuite Responsibility KnowledgeWise             Documents study and review DevSpec Review concept map Domain walkthrough Identify features Form feature sets Divide complex features Prioritize the feature sets and features Internal and external assessment DevPlan Sequence major feature sets and features Assign classes to class Owners Assign major feature sets and features to chief programmers Build a sequence diagram 4
Slide 5:    Design inspection Log design-inspection action items Product Owner The Product Owner is responsible for the overall design of the product functions. Product owner is responsible to build the product experts team so product stories can be effectively communicated to development team. Responsible to organize the product backlog Responsible for presenting a conceptual product for the product story, Teaching and promoting Blueprint methodology, Requirements are dynamic, and can be best quantitatively represented as a concept product, Maintaining the “concept product” and make it productive KnowledgeWise              Documents study and review DevSpec Domain walkthrough Identify features Form feature sets Divide complex features Prioritize the feature sets and features Internal and external assessment DevPlan Sequence major feature sets and features Assign classes to class Owners Assign major feature sets and features to chief programmers Build a sequence diagram Design inspection Log design-inspection action items 5
Slide 6: Domain Experts Domain Experts are users, clients, sponsors, business analysts or any mix of these. They use their deep knowledge of the business to explain to the developers in various levels of detail the tasks that the system must perform. They are the knowledge base that the developers rely upon to enable them to deliver the correct system. Domain experts need good verbal, written, and presentation skills. Their knowledge and participation is absolutely critical to the success of the system being built. Other important characteristics include seemingly infinite patience and endless enthusiasm about the promise of the software. The Chief architect resolves disputes over design that the Development managers cannot resolve themselves. The chief architect has the last say on all technical design issues. He or she steers the project through the technical obstacles confronting the project. The chief architect and product owner should work compensating each other, Blueprint Master Certification is recommended for such role, This position is optional, Project Manager may be also the Chief Architect, or the Product owner can serve this position, KnowledgeWise                  Documents study and review DevSpec Domain walkthrough Identify features Form feature sets Divide complex features Prioritize the feature sets and features Internal and external assessment Chief architect KnowledgeWise Documents study and review DevSpec Domain walkthrough Identify features Form feature sets Divide complex features Prioritize the feature sets and features Internal and external assessment DevPlan Sequence major feature sets and features Assign classes to class Owners Assign major feature sets and features to chief 6
Slide 7: programmers    Development Manager The Development Manager are responsible to enable the development team to be more effectively self managed. The Development Manager is responsible for leading the dayto-day development activities. A facilitating role requiring good technical skills and also good domain knowledge, the development manager is responsible for make sure the “Blueprint product stories” are correctly understood. And responsible to finish the Sprint, and for the delivery of each development cycle, Build a sequence diagram Design inspection Log design-inspection action items KnowledgeWise         Documents study and review DevPlan Sequence major feature sets and features Assign classes to class Owners Assign major feature sets and features to chief programmers Build a sequence diagram Design inspection Log design-inspection action items Development team Blueprint development team is primarily a self driven team. The development teams are very often divided to team groups and each team has the development manager, and may have group leader and tech lead. Each group must have one development manager, who’s job is to make sure there is a daily short meeting via phone, meeting, or daily meeting Each team members own development features and tasks, and are required to update the KnowledgeWise      Documents study and review DevTrack Write class and method prologs Implement classes and methods Code inspection Log code-inspection action items 7
Slide 8: effort required to finish the tasks, Each team group is responsible for their delivery at the end of the Sprint  Check in and promote to the build process DevTest  Unit test Supporting Roles Role Domain Manager FDD Responsibility For larger teams the Domain Manager leads the domain experts and is responsible for resolving differences in opinions about requirements. In a small project this role is often combined with the Project Manager role. DevSuite Responsibility KnowledgeWise        Documents study and review DevSpec Domain walkthrough Identify features Form feature sets Divide complex features Prioritize the feature sets and features Internal and external assessment Release Manager The Release Manager represents someone fussy enough to ensure Chief Programmers report progress each week. They are thorough, ensure planned and actual dates are all entered properly, and charts are printed and distributed correctly. The release manager reports directly to the Project Manager. The name for the role comes from a regular, short progress meeting DevPlan   Provide report Ensure deadline 8
Slide 9: Language Lawyer Or Language Guru Build Engineer Toolsmith System Administrator where Chief Programmers report on what has been ‘released’ into the build since the last meeting. The role is analogous to the Tracker role of Extreme Programming, and Scrum Master in Scrum. The Release Manager may combine this role with a more general administrative assistant role to the Project Manager. A Language Lawyer or Language Guru is a person who is responsible for knowing a programming language or a specific technology inside out. This role is especially useful on a project where a programming language or technology is being used for the first time and is often played by a consultant brought in for the purpose. Once the team is up to speed with the language or technology this role can be reduced until it disappears altogether. The Build Engineer is responsible for setting up, maintaining and running the regular build process. This includes managing the version control system, publishing any generated reports or documentation, and writing any build or deployment scripts. On larger projects, the version control manager or configuration manager may be a separate role, or possibly part of another department. The Toolsmith creates small development tools for the development team, test team, and data conversion team. Where necessary this may include setting up and managing a database and website that acts as the team’s knowledge repository. Many organizations have centralized IT team that provides a generic service; the toolsmith writes tools that are specific to their project. It is a role that a fresh graduate or junior programmer can play. The System Administrator configures, manages and troubleshoots any servers and network of workstations specific to the project team. This includes the development environment and any specialized testing environments. The System Admin is also often involved in the initial deployment of the system into production. DevSCM   Source code control Create daily build and release 9
Slide 10: On small systems, a single person may play all three of the Build Engineer, Toolsmith and System Engineer roles. In larger teams multiple people may play each of these roles and the System Administrator role may be split into Server Administrator, Network Administrator, and Database Administrator. Additional Roles Role Testers FDD Responsibility Testers are responsible for independently verifying that the system’s functions meet the users requirements and that the system performs those functions correctly. Testers may be part of the project team or part of an independent QA department. Deployers convert existing data to the new formats required by the new system and work on the physical deployment of new releases of the system. Again the deployment team may be part of the project team or part of some sort of Operations and System Administration department Technical Writers write and prepare online and printed user documentation. Technical writers in some organizations will have their own department that services all projects. DevSuite Responsibility DevTest  Unit test Deployers Technical Writers KnowledgeWise DevSpec DevPlan 10
Slide 11: Requirement management with Blueprint Agile Requirement management is an important part of the Blueprint Agile Requirements consists of both functional and technical, the following terms are important,    Functional requirements Technical requirement User stories Functional stories, Specification, The conceptual product The product story,    Quantify requirement and product design  It is important to define what is a conceptual product, The term “Conceptual product” is used to Important topics Bug fixing for service patch release    Bug fix planning Bug fixing along with feature development, 11