Presentation on theme: "For IBM i Environments Agile Application Lifecycle Management."— Presentation transcript:
For IBM i Environments Agile Application Lifecycle Management
Speaker Bio Christoph Heinrich, Founder and CEO CM First Group Swiss, moved to SLC in 1998 and again in 2011 Developer on IBM i since 1991 CA 2E (Synon) and CA Plex (Obsydian) Software Change Management and Application Lifecycle Management CM MatchPoint ALM
Headquarter in Switzerland Offices in USA, Italy, France 35 Employees > 400 Customers Products CM WebClient – Web and Mobile Applications with CA Plex CM MatchPoint - Application Lifecycle Manager CM Meta Analytics – Source Code Comprehension CM Power – PHP Framework for IBM i CA 2E – Application Development Platform for IBM i CA Plex – Modelbased Multiplatform Development Platform Worksoft Certify – Automated Testing Databorough X-Analysis – Source Code Analysis and Documentation Sencha / Sencha Touch
What is ALM Application Lifecycle Management (ALM) is a continuous process of managing the life of an application through governance, development and maintenance. ALM is the marriage of business management to software engineering made possible by tools that facilitate and integrate requirements management, architecture, coding, testing, tracking, and release management WIKIPEDIA
ALM Disciplines 9 DisciplineTool ModelingCA Plex / 2E DesignCA Plex / 2E Issue and defect trackingCM MatchPoint ALM Change and Configuration Mgmt.CM MatchPoint ALM / CA Plex / CA 2E Release ManagementCM MatchPoint ALM Production MonitoringCA Wily Tests and VerificationCM MatchPoint ALM / Worksoft Certify ReportingCM MatchPoint ALM TracabilityCM MatchPoint ALM PoliciesCM MatchPoint ALM / CA Plex / 2E AutomationCM MatchPoint ALM / CA Plex / 2E CollaborationCM MatchPoint ALM / CA Plex / 2E
History of Agile Manifesto for Agile Software Development We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value: Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan That is, while there is value in the items on the right, we value the items on the left more. http://agilemanifesto.org/
Definition of Agile A definition of Agile: You accept input from reality and you respond to it (Kent Beck) Twelve Principles of Agile Software Scrum Transparency Inspection Adaption Agile ALM Collaboration Integration Automation Continuous Improvement
Waterfall is… Still No. 1 The most-popular development methodology A logical approach that is partly responsible for the greatest number of large, successful projects Proven "Tried and true Suitable for projects (e.g., fixed-bid contracts) in which vast majority of requirements must be defined early if add/change is clear
Agile vs. Waterfall But Waterfall is also…. Frustrating management overhead Value is indirect and not often apparent to team members Risky Prone to dead on arrival and long tail projects Slow Not suitable for short duration projects Difficult to track Metrics are subjective and reluctance to reveal problems create a tendency to fail late in the cycle
Agile vs. Waterfall Agile is…. Quick Can handle projects as short as a couple of weeks Iterative Agile is built around a constant feedback loop Continuous Agile focuses on continuous integration, test and deployment Verifiable With a definition of done that is transparent and verifiable, project progress is quickly apparent
Agile vs. Waterfall But Agile is also… Not a silver bullet Agile exposes problems early, but does not solve all of them Disruptive Agile requires significant changes to culture, governance and IT's interactions with the rest of organization Less mature Over a dozen years old, but new to many organizations Harder to outsource Does not fit fixed bid contract model
Recommendations Reduce Iteration Duration Long iterations limit feed back, resulting in: -Delivering the wrong functionality -Delivering too much functionality -Schedule risk
Locking in Ignorance The beginning of a project is the moment when a team has the least knowledge of the domain they will ever have. This is the moment when they invent the most naive models they will ever invent. Upfront modeling locks in the team's initial ignorance." Eric Evans, Domain Language
Agile vs. Architected Most agile methodologies have no architect role. Overreaction to "big design upfront": -Requirements change quickly -The problem and solution are not well known upfront "Ivory Tower" architects did not know how code actually worked.
SCRUM Artifacts Product Backlog Ordered Items at the top are more granular than items at the bottom Maintained/re-ordered during the Backlog Grooming effort by Product Owner Sprint Backlog Committed items negotiated between team and Product Owner in Sprint Planning Meeting Scope commitment is fixed during Sprint execution Increment Sum of all Product Backlog items completed during a Sprint and all previous Sprints which produce a new increment that must be Done Usable condition regardless of Product Owner readiness to release it
SCRUM Roles Product Owner Responsible for maximizing the value of the Product and the work of the Dev team. Responsible for managing the Product Backlog Scrum Master Responsible for ensuring Scrum is understood and enacted Servant-leader for Scrum team Development Team Cross-functional team who produce a potentially releasable increment of Done at the end of each sprint Only members of this team create the increment
SCRUM Rules Definition of Done When a Product Backlog Item or Increment is described as Done, everyone needs a common understanding Shared understanding is the key as this definition drives the amount of Product Backlog Items the team can select during a Sprint Increments are usable; Product Owner may choose to immediately release it
SCRUM Events / 1 Sprint Time boxed at 4 weeks or less in which a Done, usable, and potentially releasable increment is created Consistent duration and are continuous Sprint Planning Meeting Time boxed at 8 hours for a 4 week Sprint Plans the work to be performed in the Sprint Two parts: 1) What will be delivered, 2) How will it be delivered Daily Scrum Time boxed at 15 minutes/day Finished, going to finish, obstacles/impediments today
SCRUM Events / 2 Sprint Review Time boxed at 4 hours for a 4 week Sprint Inspect the increment/Adapt the backlog Elicit feedback and foster collaboration Sprint Retrospective Time boxed at 3 hours for a 4 week Sprint Team self-inspection and creation of a plan for improving execution
SCRUM – Summarization Scrum uses time boxed techniques built upon an empirical approach (transparency, inspection, adaption) to cycle through Loading/Prioritizing Planning Execution Review Retrospection Time Boxed mini life cycles Huge risk mitigation Great opportunity for efficiency realization Enables a sustainable ecosystem Emphasis on communication, collaboration, functioning software and flexibility to adapt = more competitive!
Difficulties adopting Agile Organizational Structure / disruptive Management Support New to most team members Scrum but
Benefits of agile ALM Higher Productivity Higher Quality
INFORMATION ENGINEERING >Data Modeling >Model-Based Development >Code Generation Architected Rapid Application Development (ARAD) OBJECT ORIENTATION >Patterns >Reuse >Inheritance Architected RAD with CA Plex Page based on Title Only from Slide Layout palette. Design is cacorp 2006.
Your consent to our cookies if you continue to use this website.