In this interactive session, Scott Ambler explores a vitally important, nitty-gritty, down-in-the-weeds aspect of agile—how to take an agile model-driven development (AMDD) approach to enhance and scale your software delivery capabilities. Correctly applied, AMDD enhances your modeling and documentation efforts, streamlines agile development, and reduces false starts and rework. Scott addresses critical modeling issues that pertain to all agile projects—how to successfully model the complexities of modern-day software without getting bogged-down in mountains of paperwork, how to document systems in an agile manner, how to scale agile development methods with an agile approach to modeling and documentation, how to take an evolutionary approach to user interface and database design, and how modeling extends and supports test-driven development to address the full exploration of requirements, architecture, and design. Join Scott to dig into this vital—yet often ignored—aspect of agile development.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
MK Half‐day Tutorial 6/3/2013 1:00 PM
"Agile Model-Driven Development"
Presented by:
Scott Ambler Scott Ambler + Associates
Brought to you by:
340 Corporate Way, Suite 300, Orange Park, FL 32073 888‐268‐8770 ∙ 904‐278‐0524 ∙ [email protected] ∙ www.sqe.com
Scott Ambler Scott W. Ambler + Associates
Scott Ambler works with organizations worldwide to help them improve their software processes. Scott is the founder of the Agile Modeling (AM), Agile Data (AD), Disciplined Agile Delivery (DAD), and Enterprise Unified Process (EUP) methodologies and creator of the Agile Scaling Model (ASM). He is the coauthor of twenty-one books, including Refactoring Databases, Agile Modeling, Agile Database Techniques, The Object Primer 3rd Edition, The Enterprise Unified Process, and Disciplined Agile Delivery. Scott is a senior contributing editor with Dr. Dobb’s Journal. Visit his home page ScottAmbler.com and his Agility@Scale blog.
02/05/2013
Twitter: @scottwambler 1
Agile Model Driven Development:Best Practices for Scaling Agile
This year I really want a penguin. So in my letter to Santa Claus this year I am going to be very clear that I want a real, live penguin. Not a toy penguin. Not a penguin game. Not a penguin picture. A real, live penguin. I will even include this photo of the type of penguin that I would like with my letter.
• Take a minute to introduce yourselves to one another
• For 10 minutes, discuss within the team:• Why didn’t he get the trampoline? • Why didn’t he get the car he wanted? • Assume that he gets the penguin that he asked for. How will this
actually work out in practice• How do these observations relate to what you’ve seen in the workplace
on software development projects?• What approaches have you seen for eliciting requirements from
stakeholders? What were the advantages and disadvantages in the long run?
• AM is a chaordic, practices-based process for modeling and documentation
• AM is a collection of practicesbased on several values and proven software engineering principles
• AM is a light-weight approach for enhancing modeling and documentation efforts for other software processes such as Extreme Programming (XP), Scrum, and Unified Process (UP)
• AM is built right into Disciplined Agile Delivery (DAD)
• Agile models:– Fulfill their purpose– Are understandable– Are sufficiently accurate– Are sufficiently consistent– Are sufficiently detailed– Provide positive value– Are as simple as possible
• Agile models are just barely sufficient!
As a student I want to enroll in a course so that I can complete my degree
• Instructions:– This is a role playing exercise– One person will play the role of a traditional:
• Business Analyst• Solution/Application Architect• Technical Writer
– The traditionalist doesn’t believe the agile approach will work, and they have twenty years of “successful” traditional experience that backs up this assertion
– The other person will play the role of an agile coach
– For five minutes, have a back and forth discussion with your pair
– At the end, identify three solid points that favor the adoption of an agile approach and three solid points against it
• In agile,– Analysis is so important we do it every day– Design is so important we do it every day– Testing is so important we do it every day– and so on
• This occurs because:– Our stakeholder’s understanding of what they want evolves over time– Our understanding of the solution evolves over time– The technology, including tools, evolves over time– The business environment evolves over time
• We can no longer afford to risk treating important activities such as architecture, design, testing, and more as mere phases
• Choose one of the following activities:– Architecture– Analysis– Design– Technical writing
• Given the AMDD and DAD lifecycles, how do you think that activity will be addressed throughout development? Consider:– Project initiation/Inception– Construction– Transition
• Benefits:– The more detail you gather the greater your ability to
estimate the work required– Culturally comfortable for organizations new to agile
• Dangers:– Details will evolve over time– Some requirements will never be implemented– You increase the time required to get to Construction– Chance of “analysis paralysis” increases
• Consider:– Exploring only the details of high-priority stories at first
Exercise: Modeling and Documentation During Construction
• This is a group assignment
• As a group, take 10 minutes to discuss what your current agile team(s) are doing:– When you are iteration/sprint planning, are you doing any modeling?– Do you model throughout an iteration? If so, what are you doing?– What is your approach to producing deliverable documentation?– Is the team taking a TDD approach?
• Story: – As a Student I want to order my official transcript online so that I can
provide it to potential employers
• Acceptance tests:– Ensure the person is or has been a student– Ensure that the student are in good standing (all fees have been paid)– Ensure that the student has finished at least one course– Ensure that at least one valid ship to address is provided– …
• Unit tests for: Ensure the person is or has been a student– The student ID should be a nine-digit number– The last digit should be modulo 11 of the sum of the first 8 digits– One and only one student record should exist for the provided student
• Component teams: A subteam does all the work for a specific component.
• Internal open source: A component is developed via open source techniques.
AMDD and Large Teams
• Larger teams are often a response to greater domain complexity, technical complexity, or cultural challenges
• Inception:– You will likely need to invest a bit more time exploring the initial
requirements – You may need to take an “API First” or “Contract Model” approach to
the architecture where you define the interface to components in detail early in the project
– There will likely be a bit more initial specification
• Construction:– Product Owners will need to coordinate requirement dependencies– Architecture Owners will need to coordinate technical dependencies– TDD may need to be enhanced with parallel independent testing
• Geographically distributed/dispersed teams are usually the result of large teams or organizational culture
• Inception:– You will likely need to invest a bit more time exploring the initial
requirements – You will likely need to take an “API First” or “Contract Model” approach to
the architecture where you define the interface to components in detail early in the project
– There will likely be a bit more initial specification– Get key players together physically for Inception
• Construction:– Dispersed members will need to coordinate with their co-workers regularly– Product Owners will need to coordinate requirement dependencies– Architecture Owners will need to coordinate technical dependencies– TDD will likely need to be enhanced with parallel independent testing– Get key players together for critical milestones
• Inception:– Invest time to understand the true implications of the regulations
regarding specification, documentation, and traceability– The regulations MAY require more detailed requirements and
architecture specification, some traceability, and some level of formality of validation of the specifications
• Construction:– You may need to adopt more formal modeling and documentation
tooling– You may need to keep all artifacts in sync throughout construction– You may need to invest in traceability activities, or better yet in activities
and tooling that automatically result in sufficient traceability– TDD may need to be enhanced with parallel independent testing
• Transition:– You may need to hold final reviews and sign-offs of key artifacts– You may need to generate final artifact manifests, traceability trees, and
Modeling is an Important Aspect of Disciplined Agile Delivery
• Disciplined agilists:– Invest some up-front time exploring the initial scope– Invest some up-front time identifying a viable technical strategy– Work closely with enterprise professionals, including enterprise
architects and operations professionals, to ensure that what they’re producing is enterprise compliant
– Tailor their approach to meet the context of the situation that they face– Model throughout construction in a just-in-time (JIT) manner– Document throughout construction because they realize that
documentation is part of their overall deliverable– Work closely with their stakeholders whenever they can, not just with
• Individually, on a sheet of paper, answer the following questions:– What three new things have you learned about modeling in general?– What three new things have you learned about how modeling occurs on
an agile project?– What improvements in the way you approach modeling and
documentation can you make on your current project team?– What still puzzles you?
Please…– Take the opportunity to thank your teammates – we all learned together– Fill out the workshop evaluation form(s)– Turn in the evaluation(s) to the instructor