Agile SE/Governance
Participants • • Charles Brown Nathan Scoggin Dennis Barnabe James Nemes Leslie Blackham Jo. Ann Lane Eliot Axelband • • • Forrest Shull John Colombi Scott Lucero George Polacek Brett Peters Stas Tarchalski Facilitators: Ali Mostashari; Judith Dahmann
Agile SE/Governance • Frameworks for structuring system development efforts that enable rapid, adaptable, incremental delivery of value, guided by an overarching governance and enterprise architecture Original Statement
Agile SE/Governance • Frameworks for structuring system development efforts that enable rapid, adaptable delivery of value, guided by overarching governance • Removed ‘incremental’ because this is a potential solution • Enterprise Architecture – What is the relationship between enterprise architecture and agility? Is it a hindrance or a help? – Addressed EA in a very limited in the discussions Updated Statement
Problem Definition (1 of 4 ) • Current traditional developmental models follow waterfall/V model with clear discipline and oversight – When developers follow alternatives to the full process, they tend to reject the current SE models but the alternatives don’t provide basis for discipline/oversight – If you don’t use the full process you tend to go ‘seat of the pants’ – On an ad hoc basis, exceptions are granted for ‘heroic’ efforts • The governance issue – When you step away from the traditional V model/5000 approach, today the only option seems to be an ad hoc approach • But is the current model really the problem? – An example, GPS 3 a, has followed a V model with success with agility – This was accomplished through the way the V model was implemented • So what is the source of the problem? – We may not be using the V model effectively – Naïve implementation of the V may miss implementation options – Really good people can take any model and be successful
Problem Definition (2 of 4 ) • Urgent needs are met quickly with the objective of rapid response – Heroic responses to meet immediate needs – Trade development structure and oversight for rapid response • An example: – Need for networking of sensors which was rapidly supported with an in the field implementation of a SW solution to Immediate near term needs – Discipline/reviews etc. was provided naturally by the constant reality checks of use of the new capability in the immediate operational environment • What about the middle? – Not an immediate user need but also not a large or complex system
Problem Definition (3 of 4) • Can we develop an alternative approach which allows agility but provides discipline without full traditional SE/5000 ? – Need an approach which average folks can be successful most of the time – Are we in a business where we should leave this to average folks? ) • What is the process for – Delivering capability to the field in 2 -3 years or less – Teams of 5 to 300 – When 70% solution quickly is preferred to a more complete solution much later • What type of development are we talking about? – Full traditional SE/5000 process is for large buys or basic foundational systems – SW on commodity hardware …. This type of system may be a different class of system than the large complex platforms or weapon systems – Pace of change, means that the current model is too rigid for even for large complex systems – Now that everything is networked, it becomes even more important to find effective ways to manage agile systems given their role in these larger ‘systems’
Problem Definition (4 of 4) • Realistically there is no one process model which fits all situations…. . however, in reality – “Tailoring” only works if you have an exceptional situation – In actual execution, few things are ever really eliminated – Implementation (DIDs etc. ) is focused on the full traditional process • NSA dilemma – Lots of innovation to address new and emerging problems in creative ways – Need a way to appropriately apply discipline to these agile developments – If you go to the full SE/5000 approach, you kill the innovation • Problem summary – There are circumstances where is agility is needed – There are multiple impediments to doing things in an agile way – When folks do ‘agile’, they walk away from the traditional SE process (or they walk away from the formal governance process) – How do you apply SE to agile developments? – What is the framework for SE in an agile development?
Dimensions of the Problem • Obstacles to effective application of SE to support ‘agile development’ – – – – Organization Culture Processes Human capital Law Contractual issues (DIDs for standard process) Tools Wrong (or lack of) metric and measurements (incentives) • How can we address these different dimension of the problem?
One thing we did agree on… • There is no known approach to address all of these problems; this is a rich SE research area
Research Approaches • Review the experience and distill successful practices – Build on the urgent needs approaches based on continued iteration, regular reality check – Consider an appproach based on parallel tracks of (1) deliberate spec driven development of one increment and (2) agile future looking development, defining the next increment – Prototype early and iterate based on feedback from use – Assess other existing models (e. g. ICM) • Move from SE checklists to menus of options and calculate the risks associated with ‘skipping steps’ – What risks are you taking when you adapt the process? (e. g. Speed/agility vs risk) – Translate choices into risks and costs/savings in $ or time – Automated tool to calculate this? • Tools to automate basic SE processes (e. g. CM) – Allow you to operate in a more agile way (more concurrently) but still maintain system integrity
Research Questions (1 of 2) • How can you assess risk of an adapted Do. D/IC process? What is the risk of not implementing steps in the traditional development/SE process? • Scalability of agility? How big can an ‘agile’ process be? • Agile SW development calls for tailoring up vs tailoring down; Can we apply this to systems? • Experience vs agility. Agile processes call for mid to high capability people; can you really do this with ‘average people’ • Agility metrics, how do you measure progress in an agile development? • Types of agility – HW, SW, People • Feasibility of continuous evaluation; Can you do this on a system, does it vary by type of agility?
Research Issues (2 of 2) • Enterprise Architecture (EA) - Can you use EA as a platform to hang things on? – Can you invest in the EA upfront as framework to enable rapid development of new capabilities • How do you create the incentives to develop and adopt the ‘right’ standards to enable agility? • We understand the agile SW process; Is there an agile SE process? • SE aspects of ‘open source movement’; tension between discipline and control and an open, uncontrolled approach with opportunities • Concept of ‘layers’ – Different types of initiatives may need to have different approaches – Current layers are defined by cost – Are there other (better) ways to differentiate among types of systems and more effectively map SE/governance approaches to the layers
Contrasting Current SE Processes with Agile SW Principles • Documents vs working product “Working product is the primary measure of progress” • Product delivered at end of incremental development process vs frequent deliveries “Early and continuous delivery of working product” & “Deliver working product frequently” • Freeze change vs encouraging change “Welcome changing requirements, even late in development” • Structured interaction at key review points/milestones vs continuous interaction “Business people and developers must work together daily throughout the project” • Repeatable process with ‘average’ SEs vs need for exceptional performers “Build projects around motivated individuals Give them what they need and trust them to get the job done” • Communication via documents vs face to face exchange “Face-to-face conversation is best communications means” • Objective is to address full set of requirements vs pursuing the minimum essential “Simplicity--the art of maximizing the amount of work not done--is essential” • Formal structure vs self-organization “Best architectures, requirements, and designs emerge from self-organizing teams”
What is Agile? Agile SW Manifesto • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. • Business people and developers must work together daily throughout the project. • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done. • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. • Working software is the primary measure of progress. • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely. • Continuous attention to technical excellence and good design enhances agility. • Simplicity--the art of maximizing the amount of work not done--is essential. • The best architectures, requirements, and designs emerge from self-organizing teams. • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Скачать презентацию Agile SE Governance Participants Charles Brown
0a41aa27f57623b5e47134ab21557bb6.ppt