Tailoring your SDLC for DevOps, Agile and more
Upcoming SlideShare
Loading in...5
×
 

Tailoring your SDLC for DevOps, Agile and more

on

  • 1,338 views

A guide to tailoring your SDLC to include modern practices such as DevOps, Agile and more!

A guide to tailoring your SDLC to include modern practices such as DevOps, Agile and more!

Statistics

Views

Total Views
1,338
Views on SlideShare
1,320
Embed Views
18

Actions

Likes
0
Downloads
23
Comments
0

3 Embeds 18

https://twitter.com 7
http://www.linkedin.com 7
https://www.linkedin.com 4

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

    Tailoring your SDLC for DevOps, Agile and more Tailoring your SDLC for DevOps, Agile and more Presentation Transcript

    • Tailoring the SDLCUpdating the SDLC to include DevOps, Agile and more.April 28, 2013Confidential
    • Introduction MomentumSI encourages the tailoring of an SDLCbased on industry practices The processes, practices and bodies of knowledge(BOK) should serve as inspiration to your custom SDLC Ultimately, the practices should also providetraceability from your new SDLC back to industry bestpractices
    • InvestigateIntegrate& QAAnalysis Design Release OperateConstruct Consume EvolveStrategizeSolution LifecyclePortfolio LifecycleSDLC ExtensionsEA & Bus. Process Lifecycle ExtensionsSOA Service Lifecycle ExtensionsCompliance & Security ExtensionsChannel & UI ExtensionsITIL & Cloud Operating Model ExtensionsCommon Information ModelModel Driven EngineeringProduct Line VariabilitySpecial PurposeExtensionsOrganizational DesignRolesPositionsResponsibilitiesOrg Units / CentersReporting StructuresMeasurementsSDLC TailoringRolesDisciplinesActivitiesWorkflowsPhilosophiesBest PracticesPhilosophies& Practices
    • Processes and Bok InfluencesSoftware processes and bodies ofknowledge are mined for ‘bestphilosophies’ to direct your SDLCefforts.TailoredPhilosophies
    • PRACTICE INDEX
    • ScrumID Affects DescriptionSC1 Project Management Transparency ensures that aspects of the process that affect the outcome must bevisible to those managing the outcomes.Techniques include: ‘information radiator’, ‘sprint planning meeting’, ‘productbacklog’, ‘sprint backlog’SC2 Project Management The various aspects of the process must be inspected frequently enough so thatunacceptable variances in the process can be detected.Techniques include: ‘daily scrum meetings’, ‘burn down chart’SC3 Project Management If the inspector determines from the inspection that one or more aspects of theprocess are outside acceptable limits, and that the resulting product will beunacceptable, the inspector must adjust the process or the material beingprocessed.Techniques include: ‘daily scrum meetings’, ‘sprint review meeting’
    • ID Affects DescriptionTD1 Coding/Testing Writing a small number of new and failing automated unit test case(s) for the task at handTD2 Coding/Testing Implementing code which should allow the new unit tests cases to passTD3 Coding/Testing Re-running the new unit test cases to ensure they now pass with the new codeTD4 Coding/Testing Integrate code and tests for new code into existing code baseTD5 Coding/Testing Re-running all the test cases in the code base to ensure the new code does not break anypreviously running test casesTD6 Coding/Testing Refactoring the implementation or test code (as necessary)TD7 Coding/Testing Re-running all tests in the code base to ensure that the refactored code does not break anypreviously passing test casesTest Driven Development
    • ID Affects DescriptionFD1 Design Perform domain object modelingFD2 Design / Code Developing by featureFD3 Coding Have class / code ownershipFD4 Management Have feature teamsFD5 Testing Perform inspectionsFD6 Code / Release Have regular build scheduleFD7 Release Implement configuration managementFD8 ProjectManagementReporting / visibility of resultsFeature Driven Development
    • ID Affects DescriptionLS1 All Eliminate WasteLS2 All Minimize Paperwork / ArtifactsLS3 Project Mgmt. Implement in Small IncrementsLS4 All Decide as Late as PossibleLS5 All Decide as Low as Possible / Empower the teamLS6 All Satisfy All StakeholdersLS7 Coding/Testing Focus on TestingLS8 Management Measure Business ResultsLS9 Management Optimize Across OrganizationsLS10 All Never Stop ImprovingLean Software Development
    • ID Affects DescriptionAM1 Release Mgmt. Our highest priority is to satisfy the customer through early and continuousdelivery of valuable software.AM2 Change Mgmt. Welcome changing requirements, even late in development. Agile processesharness change for the customers competitive advantage.AM3 Release Mgmt. Deliver working software frequently, from a couple of weeks to a couple ofmonths, with a preference to the shorter timescale.AM4 Analysis Business people and developers must work together daily throughout the project.AM5 Management Build projects around motivated individuals. Give them the environment andsupport they need, and trust them to get the job done.AM6 Management The most efficient and effective method of conveying information to and within adevelopment team is face-to-face conversation.AM7 Management Working software is the primary measure of progress.AM8 Management Agile processes promote sustainable development. The sponsors, developers, andusers should be able to maintain a constant pace indefinitely.AM9 Architecture & Design Continuous attention to technical excellence and good design enhances agility.AM10 Architecture & Design Simplicity--the art of maximizing the amount of work not done--is essential.AM11 Management The best architectures, requirements, and designs emerge from self-organizingteams.AM12 Management At regular intervals, the team reflects on how to become more effective, thentunes and adjusts its behavior accordingly.Agile Manifesto
    • ID Affects DescriptionXP1 Project Mgmt. User stories are written.XP2 Project Mgmt. Release planning creates the release schedule.XP3 Project Mgmt. Make frequent small releases.XP4 Project Mgmt. The project is divided into iterations.XP5 Project Mgmt. Iteration planning starts each iteration.XP6 Management Give the team a dedicated open work space.XP7 Management Set a sustainable pace.XP8 Management A stand up meeting starts each day.XP9 Management The Project Velocity is measured.XP10 Management Move people around.XP11 Management Fix XP when it breaks.Extreme Programming (XP)
    • ID Affects DescriptionXP12 Design Simplicity.XP13 Design Choose a system metaphor.XP14 Design Use CRC cards for design sessions.XP15 Design Create spike solutions to reduce risk.XP16 Design No functionality is added early.XP17 Design Refactor whenever and wherever possible.XP18 Coding The customer is always available.XP19 Coding Code must be written to agreed standards.XP20 Coding Code the unit test first.XP21 Coding All production code is pair programmed.XP22 Coding Only one pair integrates code at a time.XP23 Coding Integrate often.Extreme Programming (cont’d)
    • ID Affects DescriptionXP24 Coding Set up a dedicated integration computer.XP25 Coding Use collective ownership.XP26 Testing All code must have unit tests.XP27 Testing All code must pass all unit tests before it can be released.XP28 Testing When a bug is found tests are created.XP29 Testing Acceptance tests are run often and the score is published.Extreme Programming (cont’d)
    • DevOpsApril 28, 2013 ConfidentialID Affects DescriptionDO1 Planning, Release Create smaller releasable units to encourage more frequent deployments to staging with small,regular releases to production.DO2 Planning, OrgDesignThe “Release engineer” is replaced with “cross-discipline delivery team”. No one person ownsthe release process, it belongs to an integrated team who takes joint ownership.DO3 Testing, Build Embrace the practice of ‘continuous builds’ and add ‘continuous testing’ to ensure that thedeliverables are of high enough quality to be released to production.DO4 Configuration Infrastructure, platforms & application components and topologies are captured as code ordigitally recordable configuration format. This practice is encouraged to happen at the verybeginning of the SDLC so it can be used to recreate dev and test environments.DO5 Build Provisioning of infrastructure and topology configuration is version controlled with app code.DO6 Architect ‘Architected for Operations’ promotes concepts that enable a system to be more easilyadministered once it is moved to production. This includes patching, starting/stopping/pausing,scaling up and down, moving between SDLC environments, DR ready, cost sensitive, etc.DO7 Architect ‘Instrumented for Operations’ promotes the use of monitors, logs, meters and other vehiclesthat enable system triage and root cause analysis.D08 Architect Scale-out WebOps. Deliver affordable, resilient architectures that scale linearly.D09 PlatformEngineeringPlatforms-on-demand. Deliver a set of template platforms that developers or testers can use toquickly provision items in the reference architecture (database, app servers, etc.)D10 Architect, Code Developers and architects are expected to “live with the application they wrote”. This meansthat they are involved in production supports after release to learn lessons on how to make appsbetter/faster/cheaper in production.
    • ID Affects DescriptionES1 Enterprise Architecture Communities over SilosES2 Management Balanced Planning over The ExtremesES3 Enterprise Architecture Governed Delivery over Ad-hoc DeliveryES4 Architecture & Design Sharing and Reuse over Building from ScratchES5 Management Business Priorities over the Enterprise SOA ManifestoEnterprise SOA Manifesto (2007)
    • SOA Manifesto (2009)ID Affects DescriptionSO1 Management Respect the social and power structure of the organization.SO2 Management Recognize that SOA ultimately demands change on many levels.SO3 Management The scope of SOA adoption can vary. Keep efforts manageable and within meaningful boundaries.SO4 Management Products and standards alone will neither give you SOA nor apply the service orientation paradigmfor you.SO5 Standards SOA can be realized through a variety of technologies and standards.SO6 Standards Establish a uniform set of enterprise standards and policies based on industry, de facto, andcommunity standards.SO7 Architecture & Design Pursue uniformity on the outside while allowing diversity on the inside.SO8 Analysis Identify services through collaboration with business and technology stakeholders.SO9 Analysis Maximize service usage by considering the current and future scope of utilization.SO10 Analysis Verify that services satisfy business requirements and goals.SO11 Change Mgmt. Evolve services and their organization in response to real use.SO12 Architecture & Design Separate the different aspects of a system that change at different rates.SO13 Architecture & Design Reduce implicit dependencies and publish all external dependencies to increase robustness andreduce the impact of change.SO14 Architecture & Design At every level of abstraction, organize each service around a cohesive and manageable unit offunctionality.
    • Harmony SOA TenetsID Affects DescriptionHS1 Design Contract first developmentHS2 Design Application framingHS3 EnterpriseArchitectureSilo search & destroyHS4 EnterpriseArchitectureProcess driven businessHS5 Project Mgmt. Spiral outside; agile insideHS6 Strategic Reuse Promote for reuseHS7 EnterpriseArchitectureGoverning for growthHS8 Project Management Service as the unit of workHS9 Configuration SOA Bill of Materials
    • OpenUP (Practices)ID Affects DescriptionOU1 Analysis Know your audienceOU2 Analysis Separate the problem from the solutionOU3 Analysis Create a shared understanding of the domainOU4 Analysis Use scenarios and use cases to capture requirementsOU5 Project Mgmt. Establish and maintain agreement on prioritiesOU6 Project Mgmt. Make trade-offs to maximize valueOU7 Analysis Manage scopeOU8 Analysis Know when to stopOU9 Analysis Maintain a common understandingOU10 Analysis Foster a high-trust environmentOU11 All Share responsibilityOU12 All Learn continuouslyOU13 Architecture & Design Organize around the architectureOU14 Architecture & Design Create the architecture for what you know today
    • OpenUP (Practices)ID Affects DescriptionOU15 Management Leverage the architecture as a collaborative toolOU16 Management Cope with complexity by raising the level of abstractionOU17 Management Organize the architecture into loosely coupled, highly cohesive componentsOU18 Management Reuse existing assetsOU19 Standards Develop your project in iterationsOU20 Standards Manage risksOU21 Architecture & Design Embrace and manage changeOU22 Analysis Measure progress objectivelyOU23 Analysis Continuously re-evaluate what you do
    • ID Affects DescriptionEU1 Analysis Acknowledge Enterprise Business Modeling as a DisciplineEU2 PortfolioManagementAcknowledge Portfolio Management as a DisciplineEU3 EnterpriseArchitectureAcknowledge Enterprise Architecture as a DisciplineEU4 Strategic Reuse Acknowledge Strategic Reuse as a DisciplineEU5 PeopleManagementAcknowledge People Management as a DisciplineEU6 EnterpriseAdministrationAcknowledge Enterprise Administration as a DisciplineEU7 Software ProcessImprovementAcknowledge Software Process Improvement as a DisciplineEU8 Operations andSupportAcknowledge Operations and Support as a DisciplineEU9 All Acknowledge Production as a PhaseEU10 All Acknowledge Retirement as a PhaseEnterprise Unified Process
    • BODIES OF KNOWLEDGE
    • About BoK’s ‘Bodies of Knowledge’ are a set of ideas, practices or techniquesthat have been shown to provide value Typically, they are very ‘action oriented’ rather than ‘philosophyoriented’ BoK’s can be mined for specific activities that you mayincorporate into your SDLC
    • ID Affects DescriptionBA1 Analysis Elicit Requirements:: Techniques: Brainstorming, Document Analysis, Focus Group, InterfaceAnalysis, Interview, Observation, Prototyping, Requirements Workshop, Reverse Engineering,Survey / QuestionnaireBA2 Analysis Structure requirements packagesBA3 Analysis Create business domain modelsBA4 Analysis Analyze user requirementsBA5 Analysis Analyze functional requirementsBA6 Analysis Analyze quality of service requirementsBA7 Analysis Determine assumptions and constraintsBA8 Analysis Determine requirements attributesBA9 Analysis Document requirementsBA10 Analysis Validate requirementsBA11 Analysis Verify requirementsBA12 Analysis Capture data and behavior models:: Techniques: Business rules, class model, CRUD matrix, datadictionary, data transformation and mapping, entity relationship diagrams, metadata definitionBA13 Analysis Capture process and flow models:: Techniques: Activity diagram, data flow diagram, eventidentification, flowchart, sequence diagram, state machine diagram & workflow modelsBusiness Analysis Body of Knowledgehttp://www.tmgmt.net/documents/BOKV1_6.pdfBABOK identifies potential tasks with some techniques rather than philosophies or tenets.
    • Business Analysis Body of KnowledgeID Affects DescriptionBA14 Analysis Usage Models:: Techniques: Prototyping, storyboards/screen flows, use case descriptions, usecase diagrams, user interface designs, user profiles, user storiesBA15 Analysis Create a requirements communication planBA16 Analysis Manage requirements conflictsBA17 Analysis Determine appropriate requirements formatBA18 Analysis Create a requirements packageBA19 Analysis Conduct a requirements presentationBA20 Analysis Conduct a formal requirements reviewBA21 Analysis Obtain requirements signoffBA22 Analysis Develop alternative solutionsBA23 Analysis Evaluate technology optionsBA24 Analysis Facilitate the selection of a solutionBA25 Analysis Ensure the usability of the solutionBA26 Analysis Support the quality assurance processBA27 Analysis Support the implementation of the solutionBA28 Analysis Communicate the solution impactsBA29 Analysis Post implementation review and assessment
    • Business Analysis Body of KnowledgeID Affects DescriptionBA30 Analysis Understand team roles for the projectBA31 Analysis Define business analyst work division strategyBA32 Analysis Define requirements risk approachBA33 Analysis Determine planning considerationsBA34 Analysis Select requirements activitiesBA35 Analysis Estimate requirements activitiesBA36 Analysis Manage requirements scopeBA37 Analysis Measure and report on requirements activityBA38 Analysis Manage requirements change
    • IT Service Mgmt. (ITIL v3)ID Affects DescriptionIT1 Operations Acknowledge Service Strategy (Financial mgmt, service portfolio management & demandmanagement)IT2 Operations Acknowledge Service Design (service catalogue mgmt., service level mgmt., capacity mgmt.,availability mgmt., IT service continuity mgmt., information security mgmt. & supplier mgmt.)IT3 Operations Acknowledge Service Transition (transition planning and support, change management, serviceasset and configuration mgmt., release and deployment mgmt., service validation and testing,evaluation & knowledge mgmt.)IT4 Operations Acknowledge Service Operation (Event mgmt., Incident mgmt., request fulfillment, problemmgmt., access mgmt., monitoring and control, IT operations & service desk)IT5 Operations Acknowledge Continual Service Improvement (CSI improvement process, Service Reporting)
    • Project Management Body of KnowledgeID Affects DescriptionPM1 Project Mgmt. Perform project integration management-Develop project charter- Develop preliminary project scope statement- Develop project management plan- Direct and manage project execution- Monitor and control project work- Perform integrated change control- Close projectPM2 Project Mgmt. Project scope management-Scope planning- Scope definition- Create work breakdown structure- Scope verification- Scope controlPM3 Project Mgmt. Project time management- Activity resource estimating- Activity duration estimating- Schedule development- Schedule controlPM4 Project Mgmt. Project cost management- Cost estimating- Cost budgeting- Cost controlPMBOK identifies potential tasks with some techniques rather than philosophies or tenets.
    • Project Management Body of KnowledgeID Affects DescriptionPM5 Project Mgmt. Project quality management- Quality planning- Perform quality assurance- Perform quality controlPM6 Project Mgmt. Project human resource management- Human resource planning- Acquire project team- Develop project team- Manage project teamPM7 Project Mgmt. Project communications management- Communications planning- Information distribution- Performance reporting- Manage stakeholdersPM8 Project Mgmt. Project risk management- Risk management planning- Risk identification- Qualitative & quantitative risk analysis- Risk response planning- Risk monitoring and controllingPM9 Project Mgmt. Project procurement management-Plan purchases and acquisitions- Plan contracting- Request seller responses- Select sellers- Contract administration & closure
    • COBITID Affects DescriptionCO1 Leadership Define a strategic IT plan.CO2 Enterprise Arch. Define the information architecture.CO3 Enterprise Arch. Determine technological direction.CO4 Management Define the IT processes, organization and relationships.CO5 IT Governance Manage the IT investment.CO6 Management Communicate management aims and direction.CO7 Management Manage IT human resources.CO8 Multiple Manage quality.CO9 Multiple Assess and manage IT risks.CO10 Project Mgmt. Manage projects.CO11 Multiple Identify automated solutions.CO12 Multiple Acquire and maintain application software.CO13 Operations Acquire and maintain technology infrastructure.CO14 Operations Enable operation and use.CO15 Multiple Procure IT resources.CO16 Multiple Manage changes.CO17 Operations Install and accredit solutions and changes.
    • COBITID Affects DescriptionCO18 Operations Define and manage service levels.CO19 Multiple Manage third-party services.CO20 Operations Manage performance and capacity.CO21 Operations Ensure continuous service.CO22 Security Ensure systems security.CO23 Management Identify and allocate costs.CO24 OCM Educate and train users.CO25 Operations Manage service desk and incidents.CO26 Operations Manage the configuration.CO27 Multiple Manage problems.CO28 Information Arch. Manage data.CO29 Operations Manage the physical environment.CO30 Operations Manage operations.CO31 Management Monitor and evaluate IT performance.CO32 Management Monitor and evaluate internal control.CO33 Management Ensure compliance with external requirements.CO34 Management Provide IT governance.
    • Appendix
    • The MSI Enterprise SOA ManifestoCommunities over SilosEnterprise Architecture focuses on creating portfolios of integrated software to fulfill a business mission. Although application silos can often becreated more quickly, the long term process of integrating silos of logic, data and policy create spaghetti architecture, demoralize teams,stagnate innovation and increase long term maintenance costs. Communities (or application portfolio domains) should adhere to enterprisestandards while each zone tailors the localized rules and regulations.Balanced Planning over The ExtremesEnterprise SOA attempts to balance planning versus the extremes (too little/too much). The popularity of the Agile movement was largely aknee-jerk reaction to the frustrations with "waterfall planning". Enterprise SOA blends long term planning with tight iterations. Think, "planningin the large, agility in the small".Governed Delivery over Ad-hoc DeliveryThe enterprise must prioritize the needs of the many over the needs of the few. Applications must be architected to fit into an ecosystem ofapplications. This will require adherence to guidelines and policies on technical standards and software processes, employed to protect the longterm interests of the community.Sharing and Reuse over Building from ScratchPortfolios of applications will have many common functional requirements. An implicit non-functional requirement in Enterprise SOA is to designfor sharing and reuse where appropriate.Business Priorities over the Enterprise SOA ManifestoI.T. systems are either a reflection of the business today or a projection of where the business is heading tomorrow. The I.T. approach must notbecome a religious battle fought at the expense of the business. On occasion, it will be in the best interest of the business to violate theprinciples of the Enterprise SOA Manifesto for the purpose of doing the right thing for the business. Appropriate planning, governance andleadership should make this the exception, not the rule.
    • OPENUP PRACTICES
    • OpenUP PracticesKnow your audienceYou cannot know how to make effective trade-offs if you do not know who the stakeholders are and what they really want. Get to knowyour stakeholders. Better yet, work closely with them to ensure that you know their needs. Start by identifying all stakeholders, and thenmaintain open and frequent communication and collaboration between them and the development team.Separate the problem from the solutionToo often, we run headlong into a solution without understanding the problem. After all, we are taught how to solve problems, not how todefine problems, so thats easier. However, this limits your understanding of the problem, imposes artificial constraints, and makes itdifficult to balance trade-offs, or to even know what the trade-offs are. Make sure that you understand the problem before you define thesolution. By clearly separating the problem (what the customer needs) from the solution (what the system must do), it is easier to maintainthe proper focus, and easier to accommodate alternate ways of solving the problem.Create a shared understanding of the domainDomain experts often have limited technical expertise; developers, architects, and testers often have limited domain expertise; andreviewers and other stakeholders often have limited time to commit to the project and learn the problem domain. As a result, people oftenhave an inconsistent or poor understanding of the problem domain, which causes communication problems and increases the likelihood ofdelivering poor value to the stakeholders. Enhance and share all parties understandings of the domain. A concise and sharedunderstanding of the problem domain enhances communication and project effectiveness. Start by defining the problem in the Visiondocument. As your understanding increases, capture key domain concepts and terminology in the Glossary to ensure a consistent, shareduse of the language of the domain.Use scenarios and use cases to capture requirementsMany companies still document requirements as a list of declarative statements, which are sometimes called the "shall statements." Theselists are often difficult for stakeholders to understand, because they require the end user to read through and mentally translate the listinto a visualization of how the requirements will interact with the system.Make use of scenarios and use cases to capture functional requirements in a form that is easy for stakeholders to understand.Nonfunctional requirements, such as performance, stability, or usability requirements, are important and can be documented as system-wide requirements, using traditional techniques.
    • OpenUP Practices (cont’d)Establish and maintain agreement on prioritiesMaking poor decisions in deciding what to develop next can result in wasted effort, delivering capabilities that are never used, or identifyingproblems late in the project (resulting in delays and even project failure). Prioritize requirements for implementation by regularly working withthe stakeholders during product evolution. Make choices that deliver value and reduce risks, while building a system that can evolve.Make trade-offs to maximize valueCost-benefit trade-offs cannot be made independent of the architecture. Requirements establish the benefits of the system to the stakeholder,while architecture establishes the cost. The cost of a benefit may influence the stakeholders perceived value of the benefit. Work with thestakeholders and team members to prioritize requirements and develop candidate architectures to implement those solutions. Use the candidatearchitectures to evaluate the cost of the benefits. Candidate solutions are considered at a high level when determining architectural feasibility.Different architectural perspectives can result in different assessments of cost versus benefit. The candidate architecture that provides the mostcoverage at the lowest cost is selected for further development.Manage scopeChange is inevitable. Although change presents opportunities to enhance stakeholder value, unconstrained change will result in a bloated,deficient system and unmet stakeholder needs. Manage change while maintaining agreements with the stakeholders. Modern processes alwaysmanage change, continually adapting to changes in the environment and stakeholder needs, assessing the impact of changes, making trade-offs,and re-prioritizing work. Stakeholder and developer expectations must be realistic and aligned throughout the development lifecycle.Know when to stopOver-engineering a system not only wastes resources, but also leads to an overly complex system. Stop developing the system when the desiredquality is achieved. Remember that "Quality is conformance to the requirements" [CRO79]. This is what gives a sense of closure to the practice.Separate the problem from the solution, ensuring that the solution does, indeed, solve the problem. After the critical requirements areimplemented and validated, the system is ready for stakeholder acceptance.
    • OpenUP Practices (Cont’d)Maintain a common understandingProject participants require a common understanding of a project to cooperate effectively. Otherwise, disorder sets in, because the teammembers cannot align their understanding and interests, and will then work with different purposes.Be proactive communicating and sharing information with project participants. Do not assume that everyone will just find what they need toknow, or that each person has the same understanding of the project as everyone else. Use work products (such as the Vision, Work Items List,and Requirements) to align the understanding between the stakeholders and developers. Use the architecture to focus and align the interests ofthe developers. At the end of each iteration, get agreement on whether the iteration goals have been reached and, if not, what actions must betaken.Foster a high-trust environmentPeople who do not feel safe will not communicate their ideas, take initiative, or admit their ignorance. In these low-trust work environments,activities must be laboriously planned in detail, carefully supervised, and extensively audited. A team working in a low-trust environment maynot be able to keep up with rapid change.Take actions that foster a high-trust environment:•Manage by intent. Create an environment where teams manage themselves, and managers serve as mentors to teams to help them completetheir objectives.•Tear down the walls. Work to remove both the physical and mental barriers that inhibit development of a common understanding amongproject participants.•Walk a mile (or 1.6 kilometers) in someone elses shoes. Respect and try to understand the perspectives of others before criticizing their ideasor responding to their criticism.•Respond to conversations with relevance. People, especially technical workers, often respond with argument or disagreement, which leads torivalry and establishes a pecking order in which only a few people contribute to the discussion. Develop and encourage behavior that valuescuriosity and relevance over argument and disagreement.•Always look to yourself first for the source of communication problems. Understand that everyone has a perspective that is largely invisibleto the individual (although it is often obvious to everyone else). Develop the habit of identifying the assumptions and prejudices within you thatlead to argument or lack of communication. Learn to overcome these in the moment of the conversation. This takes practice. There are timeswhen others may be intractable, but often the problem can be addressed by wrestling with your own perspective.•Understand the constraints of the workplace culture. Some organizations operate in a way that allows people to admit mistakes, askquestions, and experiment. Some organizations limit these expressions, but they may change, with time and effort. Some organizations have notolerance for error, and their workers put themselves in danger if they admit mistakes or experiment.
    • OpenUP Practices (Cont’d)Share responsibilityThere may be disadvantages for individuals when they work alone. Communication with the team can become sporadic, and then stop. People mayget into trouble and not ask for help, or not realize that the team is in trouble and needs their help. Their understanding of the project may becomemisaligned with the rest of the team. In the worse situations, trust breaks down as individuals see the team working at different purposes to theirinterests.While individuals have primary responsibility for their work products, responsibility for work products is shared. Nothing is someone elsesresponsibility. This may mean either taking up slack and working with someone who is lagging for some reason, or asking for help. Experiencedstaff should be extra-vigilant and watch over less-experienced staff, encouraging them to ask for help if necessary.Learn continuouslyNot only is software development a fast-developing field where technical skills rapidly become obsolete, it is also an empirical process, wheresoftware is developed in a manner that sometimes resembles trial and error. Furthermore, software is developed by teams of people who mustwork together to achieve results.Continuously develop both your technical and interpersonal skills. Learn from the examples of your colleagues. Take the opportunity to be both astudent of your colleagues, as well as a teacher to them. Always increase your personal ability to overcome your own antagonism toward otherteam members.Organize around the architectureAs projects grow in size, communication between team members becomes increasingly complex. While all team members understand the overallsystem, they can focus primarily on the one or more subsystems that they are responsible for. Organizing around the architecture also helps withcommunication by providing the team with a common vocabulary and shared mental model of the system. Communication between teammembers becomes increasingly complex.Organize the team around the architecture, and the vocabulary and a shared mental model of the system. However, be careful that individuals andteams organized this way do not form a so-called silo mentality, where they focus strictly on their subsystems and become ignorant of the othersubsystems.An architecture that reflects the organizations structure is not in itself evidence that the team has successfully organized around the architecture.If organizations and teams are not organized around the architecture, then the architecture will naturally conform to the organization, as a result ofpolitical and cultural influences. In the end, the architecture and the organization will almost always be a reflection of each other. The goal is toguide team organization from the needs of the architecture as much as possible.
    • OpenUP Practices (Cont’d)Create the architecture for what you know todayAs Albert Einstein said, make everything as simple as possible, but no simpler. Software projects are resource-constrained, and the desire ofdevelopers to create elegant solutions may lead to a system of greater complexity than the stakeholder requires. Efforts to future-proof a system ina turbulent or uncertain environment will likely lead to code bloat, which increases overall costs and complexity with few real benefits.Create architectures that address the stakeholders real needs, and provide appropriate flexibility and speed for the requirements as they areknown today. Avoid the desire, no matter how well-intentioned, to speculate on future requirements and thereby over-engineer the architecture.There is a distinction between over-architecting and building an architecture that is flexible and extensible. For example, there may not be anapparent reason for creating three architectural layers in a system, but it is probable that the system will grow in ways one cant predict, so weshould architect for that.Leverage the architecture as a collaborative toolLack of a common understanding by developers about a system leads to indecision and contrary opinions among developers, and can quicklyparalyze the project. Developers may have different mental models of the system and work at cross purposes to each other.Create and evolve the system architecture with the intention of using it to align the developers competing mental models of the system. A goodarchitecture facilitates collaboration by providing a common vocabulary for all discussions regarding the system under development.Cope with complexity by raising the level of abstractionSoftware is complex, and people have a limited capacity for coping with complexity. As a system gets larger, it is difficult for the team to develop acommon understanding of the system, because its hard to see the bigger picture.Use models to raise the level of abstraction to focus on important high-level decisions, such as relationships and patterns, rather than gettingbogged down in details. Modeling raises the level of abstraction, and allows the system to be more easily understood from different perspectives.Organize the architecture into loosely coupled, highly cohesive componentsTight coupling between components makes a system fragile and difficult to understand. Software is expensive to create, so if existing componentscan be reused, that may reduce effort required to create a system.Organize the architecture of the system into components to maximize cohesion and minimize coupling. This improves comprehension, andincreases flexibility and opportunities for re-use.Reuse existing assetsIt is wasteful to build what you can simply reuse, download, or even buy.Make every effort to reuse existing assets. Developers are often reluctant to reuse assets, because those assets do not exactly meet their needs, orthose assets are of poor quality. Be prepared to balance the savings you can realize using an existing asset, even if the asset requires you to makesome accommodation in the architecture or relax a constraint.
    • OpenUP Practices (Cont’d)Develop your project in iterationsDeveloping a system in a single, linear pass is difficult, because it makes it expensive to incorporate changes and new knowledge. Worse, it candelay the discovery and mitigation of risks, because development efforts are scheduled later in the lifecycle.Divide your project into a series of time-boxed iterations, and plan your project iteratively. This iterative strategy enables you to incrementallydeliver capabilities (such as an executable, usable subset of implemented and tested requirements) that can be assessed by stakeholders at theend of each iteration. This provides rapid and timely feedback loops, so that issues can be addressed and improvements made at a lower cost.Also, this is accomplished while you still have sufficient budget and time left to do so, and you have not gone so far ahead that major rework isrequired.Iterative development enables teams to continuously improve software throughout the development lifecycle. Focus iterations on meeting thenext management milestoneA project can appear to make progress while risks and unresolved issues pile up. Focus on bringing closure to important project issues (such asstakeholder concurrence regarding scope, and proving the proposed architecture).Divide the project into phases (such as Inception, Elaboration, Construction and Transition), with each phase having a clearly visiblemanagement milestone. The focus of each iteration within a phase is on achieving that milestone.Manage risksDeferring difficult and risky issues until later in a project significantly increases the risk of project failure. Such procrastination may lead toinvesting in the wrong technologies, a bad design, or a set of requirements that may not address stakeholder needs.Attack risks early, or they will attack you. Continuously identify and prioritize risks, and then devise strategies to mitigate them. Determine thefocus of iterations based on risks. For example, architecturally significant risks should be addressed early in the project, no later than the end ofthe Elaboration phase, when the architecture has been proven and base-lined.
    • OpenUP Practices (Cont’d)Embrace and manage changeChange is inevitable, and while change presents opportunities to enhance stakeholder value, unconstrained change will result in a bloated,deficient system and unmet stakeholder needs. Furthermore, the later in the development cycle a change is made, the more the change is likely tocost.Embrace and manage change. Embracing change helps you to build a system that addresses stakeholder needs, and managing change allows you toreduce costs and improve predictability of those changes. Changes made early in the project can usually be made with limited cost. As you progressin your project, changes can become increasingly costly.To satisfy customer needs, you typically need to introduce changes to the project, but the customer must be made aware of the impact that thosechanges have on the project cost and schedule. Understand the impact of a change in the current phase, and isolate team members fromdisruptive changes during the current iteration. Change requests are reviewed and prioritized during the current iteration, but are not acted uponuntil assigned to a future iteration. If necessary, document the changes. For informal projects, a discussion with stakeholders may be enough.Measure progress objectivelyIf you do not objectively know how your project is progressing, you do not really know if it is failing or succeeding. Uncertainty and change make asoftware projects progress difficult to measure objectively, and people are prone to making objective assessments from subjective information.Get a clear picture of project status by objectively measuring progress. The best measure of progress is the delivery of working software, which issomething that you do by taking an evolutionary approach. You can also define a set of objective metrics to collect during an iteration (for example,requirements that were implemented and validated, number of defects issued compared with number fixed) and review them as part of theiteration assessment.Continuously re-evaluate what you doOn a regular basis, ask questions and verify assumptions about the project. Regularly meet with the team to track status and identify risks andissues. This can be done daily when the team gathers to share the status of individual responsibilities and identify and address issues. At the end ofiterations, assess the status of what has been done and look for areas of improvement that can be addressed in the next iteration. Have aretrospective review at the end of the project and capture lessons learned to run future projects in a more efficient way.If we always challenge what we do and seek new, innovative ways to develop software, we improve how we work. This leads to improved projectresults.
    • LEAN SOFTWAREDEVELOPMENT
    • Lean Software PrinciplesEliminate wasteEverything not adding value to the customer is considered to be waste (muda). This includes: unnecessary code and functionality, delay in thesoftware development process, unclear requirements, bureaucracy & slow internal communicationIn order to be able to eliminate waste, one should be able to recognize and see it. If some activity could be bypassed or the result could beachieved without it, it is waste. Partially done coding eventually abandoned during the development process is waste. Extra processes and featuresnot often used by customers are waste. Waiting for other activities, teams, processes is waste. Defects and lower quality are waste. Managerialoverhead not producing real value is waste. A value stream mapping technique is used to distinguish and recognize waste. The second step is topoint out sources of waste and eliminate them. The same should be done iteratively until even essential-seeming processes and procedures areliquidated.Amplify learningSoftware development is a continuous learning process with the additional challenge of development teams and end product sizes. The bestapproach for improving a software development environment is to amplify learning. The accumulation of defects should be prevented by runningtests as soon as the code is written. Instead of adding more documentation or detailed planning, different ideas could be tried by writing code andbuilding. The process of user requirements gathering could be simplified by presenting screens to the end-users and getting their input.Thelearning process is sped up by usage of short iteration cycles – each one coupled with refactoring and integration testing.Decide as late as possibleAs software development is always associated with some uncertainty, better results should be achieved with an options-based approach, delayingdecisions as much as possible until they can be made based on facts and not on uncertain assumptions and predictions. The more complex asystem is, the more capacity for change should be built into it, thus enabling the delay of important and crucial commitments. The iterativeapproach promotes this principle – the ability to adapt to changes and correct mistakes, which might be very costly if discovered after the releaseof the system.Deliver as fast as possibleIn the era of rapid technology evolution, it is not the biggest that survives, but the fastest. The sooner the end product is delivered withoutconsiderable defect, the sooner feedback can be received, and incorporated into the next iteration. The shorter the iterations, the better thelearning and communication within the team. Without speed, decisions cannot be delayed. Speed assures the fulfilling of the customers presentneeds and not what they required yesterday. This gives them the opportunity to delay making up their minds about what they really require untilthey gain better knowledge. Customers value rapid delivery of a quality product. The Just-in-Time production ideology could be applied to softwaredevelopment, recognizing its specific requirements and environment.
    • Lean Software PrinciplesEmpower the teamThere has been a traditional belief in most businesses about the decision-making in the organisation – the managers tell the workers how to dotheir own job. In a Work-Out technique, the roles are turned – the managers are taught how to listen to the developers, so they can explain betterwhat actions might be taken, as well as provide suggestions for improvements. Most experienced project managers[who?] have simply stated thekey for a successful project – "Find good people and let them do their own job.“Build integrity inThe customer needs to have an overall experience of the System – this is the so called perceived integrity: how it is being advertised, delivered,deployed, accessed, how intuitive its use is, price and how well it solves problems.Conceptual integrity means that the system’s separate components work well together as a whole with balance between flexibility, maintainability,efficiency, and responsiveness. At the end the integrity should be verified with thorough testing, thus ensuring the System does what the customerexpects it to.See the wholeSoftware systems nowadays are not simply the sum of their parts, but also the product of their interactions. Defects in software tend toaccumulate during the development process – by decomposing the big tasks into smaller tasks, and by standardizing different stages ofdevelopment, the root causes of defects should be found and eliminated. The larger the system, the more organisations that are involved in itsdevelopment and the more parts are developed by different teams, the greater the importance of having well defined relationships betweendifferent vendors, in order to produce a system with smoothly interacting components.Lean thinking has to be understood well by all members of a project, before implementing in a concrete, real-life situation. “Think big, act small, failfast; learn rapidly” – these slogans summarize the importance of understanding the field and the suitability of implementing lean principles alongthe whole software development process. Only when all of the lean principles are implemented together, combined with strong “common sense”with respect to the working environment, is there a basis for success in software development.