• Share
  • Email
  • Embed
  • Like
  • Private Content
Zwinny rational
 

Zwinny rational

on

  • 1,058 views

 

Statistics

Views

Total Views
1,058
Views on SlideShare
1,058
Embed Views
0

Actions

Likes
0
Downloads
15
Comments
0

0 Embeds 0

No embeds

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
  • Common agile practices: iterative, reflect, adapt, incremental, feedback Continuous-ness Feedback-bone Continues to evolve
  • The Agile Scaling Model (ASM) defines a roadmap for effective adoption and tailoring of agile strategies to meet the unique challenges faced by a system delivery team. The first step to scaling agile strategies is to adopt a disciplined agile delivery life cycle which scales mainstream agile construction strategies to address the full delivery process from project initiation to deployment into production. The second step is to recognize which scaling factors, if any, are applicable to a project team and then tailor your adopted strategies accordingly to address the range of complexities with the team faces. The focus of Core Agile Development is construction. Clearly important, but not the full picture. Core/mainstream approaches focus on the fundamentals, with value driven lifecycles where high-quality potentially shippable software is produced on a regular basis by a highly collaborative, self-organizing team. Focus is on small (<10) co-located teams developing straightforward systems. Agility@Scale is disciplined agile development where one or more scaling factors is applicable. It is important to recognize that team size is only one of several issues that agile teams face at scale. The scaling factors which an agile team may face to a lesser or greater extent, includes team size, physical distribution, organizational distribution, regulatory compliance, cultural or organizational complexity, technical complexity, and enterprise disciplines (such as enterprise architecture, strategic reuse, and portfolio management). Our focus is around disciplined agile where we take the full lifecycle into account as a starting point for real-world development and on Agility@Scale for organizational/enterprise-level development See http://www.ibm.com/developerworks/blogs/page/ambler?tag=ASM for details
  • Effectively “build on steroids” You want to rebuild the system when something changes. On dev sandbox you’ll be building your component(s) several times a day. On integration sandbox you;ll rebuild after promoting your code changes. Ideally you should rebuild this environment at least nightly The pre-production environments will be built less often, perhaps weekly for example, depending on system size and need to do so. You may deploy into production only once a quarter or once a year for example, even though your development iterations are much shorter (e.g. two weeks). Integration support BF and RTC both have automated build functionality Software analyzer does static code analysis. This should be particularly interesting to agile teams looking to take the “next step” in build quality Deployment of code/components BF automates deployment between sandboxes/environments Reporting defects back to the dev team: ClearQuest is used to communicate defect reports/enhancement requests back to the dev team from testers or support people Independent testers can record defects as work items in RTC
  • Need to build (compile test and potentially run code analysis) on a regular/continuous basis RTC includes build functionality BuildForge main functionality is around build and deployment Risk/Value Driven lifecycle RUP phases and milestones help to scale agile Inception focuses on driving out business risk Elaboration drives out tech risk through creation of end-to-end working skeleton of the system Construction drives out delivery risk Transition drives out deployment risk Proven value is produced via creation of potentially shippable software each iteration (might not be true of Inception)
  • With TDD you write a single test then just enough code to fulfill that test. Because you write the test first you are effectively specifying as well as validating the software On truly agile teams the majority of requirements and design specification is done via TDD The implication is that the majority of testing is done by the development team, not the test team. This is a significant difference from the traditional approach You need to be good at build to pull this off RTC and RAD ship with xUnit tools (e.g. JUnit for Java) for design-level TDD People download Fit/Fitnesse for requirements-level TDD BuildForge can run the build, part of which is to run the regression test suite See www.agiledata.org/essays/tdd.html for a detailed overview of TDD
  • Agile can mean different things to different people. Finding common ground can help to avoid misunderstandings. As a result of working with companies who are undertaking Agile Development, IBM Rational has made some key observations: Agile software development can be significantly different from one organization to another. Agile is not a “one size fits all” proposition Agilists do a lot more testing than traditional teams. In fact they often write a test before they write sufficient production code to fulfill that test; then they iterate Agilists work together very closely and, ideally, work closely with their stakeholders Changing requirements are seen as a competitive advantage, as long as you can act on them, not as something that you need to prevent Agilists deliver working software every iteration, providing concrete evidence of actual progress on the project. Daily builds, or even multiple times a day are highly desirable Shorter iterations are desirable, from as short as one-to-two weeks, 4 weeks as a common recommendation, although up to 8 weeks will occur at scale
  • Introduction to Disciplined Agile Delivery - Instructor Notes Module 1 - Agile and Discipline Agile Delivery Overview The disciplined agile delivery lifecycle expands upon the Scrum construction lifecycle in three important ways: It has explicit project phases, recognizing that agile delivery is really iterative in the small and serial in the large. It includes a full range of practices. This includes initial requirements and architecture envisioning at the beginning of the project to increase the chance of building the right product in the right manner, as well as system release practices. It includes more robust practices. The lifecycle of this figure explicitly reworks the product backlog in the previous slide into the more accurate concept of a ranked work item list. Not only do agile delivery teams implement functional requirements, they must also fix defects (found through independent testing or by users of existing versions in production), provide feedback on work from other teams, take training courses, and so on. See www.ambysoft.com/essays/agileLifecycle.html
  • Agile teams treat requirements as a prioritized stack The work item list concept is an extension of Scrum’s “Product Backlog” – you need to manage more than just requirements, you also have to manage defects, and non-functionality work (such as reviewing artifacts of other teams, going on vacation, going on training, …) RRC is used for initial sketching of requirements diagrams and capturing high-level information. It streamlines requirements modeling while supporting electronic capture and sharing of the information. RTC has a work item list functionality both for the team and for individuals. Requirements and defects are captured as work items. In some ways work items are the electronic version of what co-located agile teams use index cards for. ClearQuest can be used to manage requirements, as long as they’re kept at a high-level. The CQ product team works like this. ReqPro, when used in a light manner, is applicable for agile teams that are in regulatory environments, distributed, or large. See www.agilemodeling.com/essays/agileRequirements.htm for a detailed overview of agile requirements change management
  • Most agile teams do not want to discuss modeling, nor modeling tools Most agile teams use inclusive tools such as paper and whiteboards for modeling and are very happy doing so Ideally detailed specifications are captured as tests, not documents or models (See TDD slides) Several organizations have struggled/failed to get their Agile MDA/Agile CASE/Agile DSM message heard Most modelers really don’t seem to understand agile, and most agile teams don’t have the patience for them Modeling either has to be light (high-level) or very close to the code Dangerous topics: Detailed platform independent/logical modeling isn’t well respected Talking about modeling tools with agile teams is a dangerous gambit at best Resources: See www.agilemodeling.com/essays/amdd.htm for details about AMDD See www.agilemodeling.com/essays/bestPractices.htm for AMDD best practices See www.ambysoft.com/surveys/modelingDocumentation2008.html for summary of a survey that explored whether agilists model and write documentation (they’re just as likely as traditionalists to do both)
  • TDD isn’t sufficient: TDD enables you to validate your system to your current understanding of the intent of your stakeholders TDD is the equivalent of testing against the specification, replacing a lot of the grunt work done on traditional teams by the testers TDD assumes that your stakeholders can communicate their requirements and that developers can test Agile teams address some of the communication risk by closely working with stakeholders, developing working software on a regular basis, and iterating Agile teams address the skills risk through close collaboration and a cultural value for quality BUT, stakeholders often miss requirements, particularly non-functional/quality of service requirements and often don’t understand integration issues, enterprise issues, … These issues should be addressed by independent testing efforts The independent testers should try to break the system and report back change stories (defect reports and enhancement requests) to the development team The bulk of the testing effort is done by the development team, but the complex testing is done by the testers Our testing tools can be used by independent testers to address issues not easily addressed by OSS tools CQ and RTC can be used to capture the change stories The change stories are prioritized and estimated by the dev team and then treated like any other type of requirement Because the change story is a requirement, it can now be addressed via TDD and the tests around it included in the team’s regression test suite See www.ddj.com/dept/debug/196603549 for detailed discussion
  • In the early days, agile development was applied to projects that were small in scope and relatively straightforward. Today, organizations want to apply agile development to a broader set of projects. Agile needs to adapt to increasing complexity. Agility@Scale is about explicitly addressing the complexities that disciplined agile delivery teams face in the real world. The agile scaling factors are: Geographical distribution. What happens when the team is distributed within a building or across continents? Team size. Mainstream agile processes work well for small teams (10-15), but but what if the team is fifty people? One hundred people? One thousand people? Compliance requirement. What if regulatory issues – such as Sarbanes Oxley, ISO 9000, or FDA CFR 21 – are applicable? Domain complexity. What if the problem domain is intricate ( such as bio-chemical process monitoring or air traffic control), or is changing quickly (such as financial derivatives trading or electronic security assurance). More complex domains require greater exploration and experimentation, including but not limited to prototyping, modeling, and simulation. Organization distribution. Sometimes a project team includes members from different divisions, different partner companies, or from external services firms. Technical complexity. Working with legacy systems, multiple platforms, or blending disparate technologies can add layers of technical complexity to a solution. Sometimes the nature of the problem is very complex in its own right. Organizational complexity. The existing organizational structure and culture may reflect traditional values, increasing the complexity of adopting and scaling agile strategies. Different subgroups within the organization may have different visions as to how they should work. Individually, the strategies can be quite effective, but as a whole they simply don’t work together effectively. Enterprise discipline. Organizations want to leverage common infrastructure platforms to lower cost, reduce time to market, and to improve consistency. They need effective enterprise architecture, enterprise business modeling, strategic reuse, and portfolio management disciplines. These disciplines must work in concert with, and better yet enhance, the disciplined agile delivery processes. Each scaling factor has a range of complexities associated with it. Each team faces a different combination of factors, and therefore needs a process, team structure, and tooling environment tailored to meet their unique situation. Pick a few scaling factors and discuss how they influence agile adoption. For example, geographical distribution (co-located at one extreme and multiple time zones, working hours, and a distributed team at the other).
  • The more distributed your team becomes the greater the complexity Even if you have people working on different floors in the same building the team is effectively distributed The more distributed people are the more difficult it becomes to succeed See the Dr. Dobb’s 2008 Agile Adoption survey (www.ambysoft.com/surveys/) which found that co-located agile teams had a 83% success rate, near-located teams a 72% success rate, and far-located teams a 60% success rate. The implication is that if your team is distributed you need to address the inherent risk through improved tooling and process support. RTC for distributed development ClearCase for maintaining project assets BuildForge for distributed build ClearQuest for maintaining defects and potentially requirements shared between subteams RMC for defining a common process Modeling tools for defining business models and more importantly architecture models (team organization and architecture should reflect one another) The Redbook can be downloaded from www.ibm.com
  • The larger the team the greater the complexity Large teams are organized into subteams As teams grow in size many of the open source tools which work in less complex situations are no longer sufficient You may want to add use a “iteration 0" to define the initiative at a high level and then decompose into releases comprised of many empowered small teams. Modeling tools (RRC and design tools) used to capture business and architectural models to help drive consistency between subteams ClearCase used to store shared artifacts BuildForge used to build the system across sites RMC used to define the shared process followed by the subteams ReqPro used to manage requirements assigned to various subteams RTC used to improve collaboration within team RAM used to manage assets to be shared across subteams Policy tester used to ensure that subteams are following consistent coding practices
  • Most teams have to comply either to government regulations or internal corporate regulations, increasing the complexity of their solution and approach to development Want to automate compliancy as much as possible Open source tools rarely address compliancy issues Read the regulations that you’re complying too Process must reflect compliancy needs Not all projects will need to comply to all guidelines Need flexible process solutions RMC can be used to maintain compliancy guidelines, Compliancy guidelines can be maintained as separate plugins that can be tailored in as needed RTC’s process enablement can be used to ensure people follow regulations ClearCase is used to put everything under version control, important for many regulations ClearQuest supports change tracking and traceability ReqPro supports traceability and requirements defn Policy Tester can validate that developers are following common conventions The modeling tools used to capture requirements and design as well as support traceability BuildForge maintains logs regarding build successes/failures
  • As applications grow in complexity the more complex the tooling and process (in general) Complexity can be increased by low quality legacy systems and data sources Some systems are inherently complex, even if they’re completely new Modeling tools used to model the complexities RTC used to promote collaboration within team, enabling people to deal with the complexities more effectively BuildForge to build the system earlier in lifecycle, helping to address complexities around integration Testing tools to validate that the system actually addresses the complexities ClearCase to store artifacts RAD to develop the system RAM to maintain shared frameworks and components to address the complexities
  • Thank you!

Zwinny rational Zwinny rational Presentation Transcript

  • Zwinny Rational  Martin Stenkilde, CISSP IBM Rational Tiger Team Leader, CEE
  • Agenda
    • Introduction
    • Core Agile Development – living Scrum with RTC
    • Scaling up Agile
      • Disciplined Agile Delivery - Agile in an Enterprise context
      • Agility@Scale – dealing with scaling factors, beyond traditional Agile
    • Summary and Conclusions
    • * Most content thanks to Scott Ambler and Jean-Yves Rigolet…
  • Agile Methodologies or Religions?
    • Scrum
      • by far the most widely adopted
      • Out of the box support in RTC
    • Feature Driven Development
    • XP
      • Fairly narrow, development-focused but also useful
    • RUP
      • Tackle risks up front
      • Be iterative and adaptive
    • Our position is to defuse the religious/brand name debate and focus on the practices
  • Our Practices – the Jazz Way milestones first API first end game retrospectives always have a client continuous integration community involvement new & noteworthy adaptive planning continuous testing consume your own output component centric drive with open eyes validate reduce stress learn enable attract to latest transparency validate update dynamic teams show progress enable explore validate live betas feedback sign off common agile practices common Open Source practices scaling-up practices Our unfair advantage
  • Agenda
    • Core Agile Development – living Scrum with RTC
    • Scaling up Agile
      • Disciplined Agile Delivery - Agile in an Enterprise context
      • Agility@Scale – dealing with scaling factors, beyond traditional Agile
    • Summary and Conclusions
    • * Most content thanks to Scott Ambler and Jean-Yves Rigolet…
  • Agile Scaling Model (ASM)
    • Core Agile Development
    • Focus is on construction
    • Goal is to develop a high-quality system in an evolutionary, collaborative, and self-organising manner
    • Value-driven lifecycle with regular production of working software
    • Small, co-located team developing straightforward software
    • Disciplined Agile Delivery
    • Extends agile development to address full system lifecycle
    • Risk and value-driven lifecycle
    • Self organisation within an appropriate governance framework
    • [email_address]
    • Disciplined agile delivery and one or more scaling factors applies:
      • Team size, GDD, technical complexity, org. complexity, …
  • Core Agile Development Core Agile Development
  • Example Team: Rational Team Concert for Z/OS Research Haïfa, Israel 3 4 2 6 10 3 8 1 37 developers Development Beijing, China Development Pornichet, France Mgt, Development Raleigh, US UA San Jose, US Development Austin, US Arch, Development Paris, France Development Perth, Australia Rational Team Concert SCM Work Items Build
  • Our (old) Pain Points…
    • joining a team
    • get my environment configured to be productive
    • what is happening in my team
    • collecting progress status
    • following the team’s process
    • ad hoc collaboration/sharing of changes
    • starting an ad hoc team
    • is the fix in the build?
    • run a personal build
    • tracking a broken build
    • why is this change in the build?
    • reconstructing a context for a bug/build failure
    • interrupting development due to a high priority bug fix
    • working on multiple releases concurrently
    • tracking the code review of a fix
    • referencing team artifacts in discussions
    • how healthy is a component?
    • collecting project data/metrics?
    • keeping plans up to date
    Boring and painful Team awareness Build awareness Project awareness
  • Drinking our own Champagne
    • RTCz development project
      • Self hosting on System z
        • Access from Jazz.net
      • ‘ RTCz for System z Project’
      • Iterative, based on the Scrum template
    • Geographically Distributed Development team
      • 4 main Scrum teams
        • RTP (Raleigh, US)
        • FASL (France & Australia)
        • BF (Austin, US)
        • UA (San Jose)
    • 2 parallel development lines
      • No code maintenance
      • Main development
        • Release v2.0
        • Post v2 development
      • Product Delivery
  • Scrum applied
    • RTCz development process
      • Based on the standard Scrum process template
      • Roles: Stakeholder, Product Owner, Scrum Master, Team Member
      • Artifacts: Work Items, Product Backlog, Sprint Backlogs
    • Minor process adaptations
      • New role: PMC ( Project Management Council - based on Stakeholder role)
      • New Minutes work item
      • Updated permissions
        • PMC can update Plans
        • Limited operations for externals
      • New automatic tasks when joining a team
        • [Joining a Team] Update your calendar with your Scheduled Absences
        • [Joining a Team] Update your Work Environment
  • Sprint planning detailed
    • First days of each Sprint
      • Sprint directions from Product Owner
      • Analyze Stories with the Architects
    • All Scrum team members are involved
    • 1 Sprint planning per Scrum team
    • Check time budget
      • Verify absences in RTCz
    • From Product Backlog ...
      • Query Work items
      • Team members try to fully understand User Stories with the help of the Architects
      • Give estimates using the Planning Poker technique
    • ...To Iteration Plan
      • Fill Sprint backlog with selected Stories based on team velocity and priorities
  • Continuous Integration Rational Build Forge Rational Team Concert
    • Daily builds are a good start
    • Agilists update and test their code constantly
    • Therefore they need to build the system constantly
      • Compile
      • Regression testing
      • Static code analysis
    • Critical points:
      • Must be automated
      • Don’t forget database integration
      • Need a protocol for automatically deploying builds to higher-level sandboxes
      • Doesn’t mean that you’re deploying into production every 2 weeks
  • Share & build source code Integration Streams and flows Build definitions Source code Components Pending updates Build results
  • Regular Deployment of Working Software
    • How many projects have you seen that:
      • Were “90% complete” for months?
      • Delivered wonderful plans but no software?
      • Delivered wonderful models, but no software?
    • The only accurate measure of software development is the delivery of software
      • Deliver something at the end of each cycle/iteration
      • Iterations should be short
      • At all points in time stakeholders can see what they’ve gotten for their investment to date
    RMC Practices: Iterative Development Rational Build Forge Rational Team Concert Rational Method Composer
  • RTCz V2 Development Rhythm
    • Monthly Sprints
    • 9 iterations
      • Initial iteration (training, envt set up,...)
      • 5 development iterations
        • All Sprints include FVTs
      • End-game & Cleanup
        • Including SVTs, TVTs, GVTs
    • 3 phases in all development iterations
      • Planning (2-3 days)
      • Development
      • Stabilization (3-4 days)
  • Test/Behavior Driven Development (TDD/BDD) Rational Build Forge Rational Team Concert Rational Application Developer
    • Automated acceptance testing drives your detailed requirements efforts
    • Automated developer testing drives the detailed design of the system
    • Tests form the majority of your detailed specifications
    • You’ll still need some high-level models to provide overviews
    • This is the first time in IT history that developers are motivated to keep the specifications up-to-date
    • An example of single sourcing information
  • Agenda
    • Scaling up Agile
      • Disciplined Agile Delivery - Agile in an Enterprise context
      • Agility@Scale – dealing with scaling factors, beyond traditional Agile
    • Summary and Conclusions
    • * Most content thanks to Scott Ambler and Jean-Yves Rigolet…
  • What is disciplined agile delivery?
    • Disciplined agile delivery is an evolutionary (iterative and incremental) approach that regularly produces high quality solutions in a cost-effective and timely manner via a risk and value driven lifecycle.
    • It is performed in a highly collaborative, disciplined, and self-organizing manner within an appropriate governance framework, with active stakeholder participation to ensure that the team understands and addresses the changing needs of its stakeholders.
    • Disciplined agile delivery teams provide repeatable results by adopting just the right amount of ceremony for the situation which they face.
    • “ Fits just right” process
    • Continuous testing and validation
    • Consistent team collaboration
    • Rapid response to change
    • Ongoing customer involvement
    • Frequent delivery of working solutions
    Core Principles
  • The disciplined agile lifecycle: An extension of Scrum
  • Agile Requirements Management Rational Requirements Comp RMC Practices: Requirements Management, Use-Case Driven Development Rational Team Concert Rational Requisite Pro
    • Requirements are prioritized by stakeholders
    • Requirements are estimated by the development team
    • Requirements will evolve throughout the project
    • Stakeholders see working software each iteration
    • Stakeholders can change the level of funding as appropriate
    • Stakeholders determine when “enough is enough”
    Rational DOORS
  • Agile Model Driven Development (AMDD) RMC Practices: Shared Vision, Evolutionary Architecture, Evolutionary Design, TDD, Component Software Architecture Rational Design Tools Rational Requirements Comp Rational Requirements Composer
  • Concurrent, Independent Testing Rational Testing Tools Rational Team Concert Rational Quality Manager Independent Testing Const. Iteration … Const. Iteration Transition Iteration(s)
    • Effective agile teams push their working builds to an independent test team on a regular basis for investigative testing
    • Defects must be prioritized and put back on the team’s work stack
    • Defects == Requirements
    • Scales TDD: TDD is a form of confirmatory testing. TDD is a great start, but it’s not the full testing picture
    • Critical strategy for addressing non-functional requirements
  • Coordinate our tests in RQM
    • All defined in Rational Quality Manager
      • FVT, SVT & Performance Test Plans
    • Defined by developers
      • During the Stabilization phase
    • Executed by all members
      • Developers, release engineer, ..., and even managers
      • Test execution records
    • Creating Defects on execution failure
    • Formal reviews
      • Test cases approvals by Product Owner & ScrumMasters
    • Metrics & charts on quality presented at Sprint stakeholders meetings
    Test case design Execution report
  • Agile scaling factors Domain Complexity Straight -forward Intricate, emerging Compliance requirement Low risk Critical, audited Team size Under 10 developers 1000’s of developers Co-located Geographical distribution Global Enterprise discipline Project focus Enterprise focus Technical complexity Homogenous Heterogeneous, legacy Organization distribution (outsourcing, partnerships) Collaborative Contractual Disciplined Agile Delivery Flexible Rigid Organizational complexity
  • Agile inhibitors – we can help overcome…
  • Geographical Distribution
    • Distributed teams
      • Increase communication risk
      • Increase risk of delivering the wrong product
      • Leverage people in disparate locations
      • Require greater discipline
      • Require improved tooling
    • Best practices
      • Initial architecture envisioning
      • Invest in travel
      • Invest in communication/collaboration technologies
    Rational Build Forge Rational Team Concert Rational Method Composer Rational Requirements Comp Rational DOORS
  • Collaborate using Work items and Plans Instant collaboration / share context Various levels of work planification Discuss/exchange work with members
  • Team Size
    • Large teams
      • Increase management complexity
      • Increase communication overhead
    • Best practices
      • Initial architecture envisioning
      • Architecture drives team organization
      • Architecture ownership team
      • Program management team
      • Stakeholder team
      • Requirements management
    Rational Build Forge Rational Method Composer Rational Asset Manager Rational Team Concert Rational Quality Manager Rational DOORS
  • Check the project status & health Burndown charts Various project health dashboards Team communication
  • Regulatory Compliance
    • Recognize that this is a reality for many teams
    • Best practices
      • Read and understand the regulations
      • Automate as much as possible
      • Embed compliancy into your culture
      • Lean development governance
    Rational Team Concert Rational Policy Tester Rational Quality Manager Rational DOORS
  • Integrating with existing Governance systems
    • Highly regulated industries require strict control, auditability, archive…
      • Rigorous Change Management
      • Auditable builds, archives..
    • May require integrating with existing CM, SCM, and Build systems
    • Teams can do their daily work in more agile tools and deliver to the “mother ship” as needed
      • Bridges can be automated or manual
    • Our example team does this with our formal support system
    Corporate Repository Scrum Repo
  • Technical Complexity
    • Complex applications
      • Are the norm, not the exception
      • Legacy systems and data sources are often less than perfect
      • Legacy asset owners struggle with agile approaches
    • Best practices
      • Multi-disciplined teams
      • Multi-disciplined people – Generalizing specialists
      • Code refactoring
      • Database refactoring
      • Iterative development
      • Continuous integration
      • Short iterations
    Rational Design Tools Rational Build Forge Rational Asset Manager Rational Testing Tools Rational Team Concert Rational Quality Manager Rational DOORS
  • Managing Technical Complexity – Tracking Adoptions
    • The RTCz team builds on the Jazz Foundation
    • Jazz Foundation architectural changes and API evolution need to be coordinated across adopters
    • The Jazz teams have instituted formal Adoption tracking
  • Agenda
    • Summary and Conclusions
  • Walker Royce’s Top Ten Agile Principles for Success
    • Reduce uncertainties by addressing architecturally significant decisions first.
    • Establish an adaptive life-cycle process that accelerates variance reduction.
    • Reduce the amount of custom development through asset reuse and middleware.
    • Instrument the process to measure cost of change, quality trends, and progress trends.
    • Communicate honest progressions and digressions with all stakeholders.
    • Collaborate regularly with stakeholders to renegotiate priorities, scope, resources, and plans.
    • Continuously integrate releases and test usage scenarios with evolving breadth and depth.
    • Establish a collaboration platform that enhances teamwork among potentially distributed teams.
    • Enhance the freedom to change plans, scope, and code releases through automation.
    • Establish a governance model that guarantees creative freedoms to practitioners.
    http://www.drdobbs.com/architecture-and-design/222300750
  • Agile does scale, and IBM Rational can help
    • In addition to the development practices of Scrum and other Agile methodologies, Disciplined Agile Delivery practices can help deliver complex software and systems in a repeatable and predictable way.
    • Rational provides tools that support these practices.
    • Rational and our customers are using these tools to successfully scale Agile in many different dimensions.
    Delivering greater value from your investments in software
  • © Copyright IBM Corporation 2010. All rights reserved. The information contained in these materials is provided for informational purposes only, and is provided AS IS without warranty of any kind, express or implied. IBM shall not be responsible for any damages arising out of the use of, or otherwise related to, these materials. Nothing contained in these materials is intended to, nor shall have the effect of, creating any warranties or representations from IBM or its suppliers or licensors, or altering the terms and conditions of the applicable license agreement governing the use of IBM software. References in these materials to IBM products, programs, or services do not imply that they will be available in all countries in which IBM operates. Product release dates and/or capabilities referenced in these materials may change at any time at IBM’s sole discretion based on market opportunities or other factors, and are not intended to be a commitment to future product or feature availability in any way. IBM, the IBM logo, the on-demand business logo, Rational, the Rational logo, and other IBM products and services are trademarks of the International Business Machines Corporation, in the United States, other countries or both. Other company, product, or service names may be trademarks or service marks of others.
  • Resources
    • Agile/Scrum
      • Agile Manifesto: http://agilemanifesto.org/
      • Wikipedia: http://en.wikipedia.org/wiki/Agile_software_development
      • Wikipedia: http://en.wikipedia.org/wiki/Scrum
      • Scrum Alliance: http://www.scrumalliance.org/
      • Scrum Community: https://scrumcommunity.pbwiki.com /
      • Rational agile development: http://www-01.ibm.com/software/rational/agile/
    • IBM Rational Team Concert for System z
      • Jazz community: https://jazz.net/projects/rational-team-concert-z/
      • Articles & papers:
        • In tune with IBM Jazz and IBM Rational Team Concert entreprise development tools , by JY. Rigolet : http://www-949.ibm.com/software/rational/cafe/docs/DOC-2943
        • Easier, faster collaborative development by globally distributed teams, series by R. Radcliffe: http://www.ibm.com/developerworks/rational/library/09/rationalteamconcertsystemzjazz1/index.html
        • Drinking our own Champagne – In the concert of RTCz development , by JY. Rigolet: http://jazz.net/library/presentation/393