SUBJECT CODE : 3171610 As per New Syllabus of GUJARAT TECHNOLOGICAL UNIVERSITY Semester - VII (IT) Professional Elective - IV AGILE DEVELOPMENT AND UI / UX DESIGN Avinash R. Jha M.Tech.(CSE), B.E.((T), Formerly Asst. Professor, Department of Information Technology, Laxmi Institute of Technology, Sarigam, Gujarat, India Manthan J. Surti M.E.(IT), B.E.(1T), Assistant Professor, Department of Information Technology, Laxmi Institute of Technology, Sarigam, Gujarat, India => TECHNICAL PUBLICATIONS An Up-Thrust for Knowledge aK i z @AGILE DEVELOPMENT AND UI / UX DESIGN Subject Code : 3171610 Semester - VIl (Information Technology) Professional Elective - IV © Copyright with Authors Al publishing rights (printed and ebook version) reserved with Technical Publiestions. No port of this book should be reproduced in any form, Electronic, Mechanical, Photocopy or any information storage and retrieval system without prior permission in writing, from Technical Publications, Pune. Published by : TECHNIGAL | ** Pier" Ofice No.1, 412, Shaniwar Peth, PUBLICATIONS | Pu" - 411030, MS. INDIA. Ph.: +91-020-24495496/97 a Email : soles@technicolpublications.org Website : www-technicalpublications.org Printer = Yori Pinter: & Binders SeNo. 10/1A, Ghule Industrial Estate, Nanded Village Rosd, Tal. - Havel, Dat. - Pine - 411041 ISBN 978-93-91867-44-6 Il 567446 978939156744611] dyPREFACE The importance of Agile Development and UI / UX Design is well known in various engineering fields. Overwhelming response to our books on various subjects inspired us to write this book. The book is structured to cover the key aspects of the subject Agile Development and UI / UX Design. The book uses plain, lucid language to explain fundamentals of this subject. The book provides logical method of explaining various complicated concepts and stepwise methods to explain the important topics. Each chapter is well supported with necessary illustrations, practical examples and solved problems. All the chapters in the book are arranged in a proper sequence that permits each topic to build upon earlier studies. All care has been taken to make students comfortable in understanding the basic concepts of the subject. Representative questions have been added at the end of each chapter to help the students in picking important points from that chapter. The book not only covers the entire scope of the subject but explains the philosophy of the subject. This makes the understanding of this subject more clear and makes it more interesting. The book will be very useful not only to the students but also to the subject teachers. The students have to omit nothing and possibly have to cover nothing more. We wish to express our profound thanks to all those who helped in making this book a reality. Much needed moral support and encouragement is provided on numerous occasions by our whole family. We wish to thank the Publisher and the entire team of Technical Publications who have taken immense pain to get this book in time with quality printing. Any suggestion for the improvement of the book will be acknowledged and well appreciated. Authors Aeinash R. Jha Manthan (2. Busts Dedicated to Parents, Fulends and Students aySYLLABUS Agile Development and UI/UX Design - (3171610) Credits Examination Marks g Theory Marks Practical Marks “Total Marks ESE (E) PA(M) | ESE(V) | PA(D 3 70 30 0 0 100 AGILE DEVELOPMENT : Agile Practices, Overview of Extreme Programming, Planning, Testing, Refactoring. (Chapter - 1) AGILE DESIGN : What is Agile Design ?, SRP : The Single-Responsibility Principle, OCP : The Open- Closed Principle, LSP : The Liskov Substitution Principle, DIP : The Dependency- Inversion Principle, ISP : The Interface-Segregation Principle. (Chapter - 2) UX and UX Design, The Wheel : UX Processes, Lifecycle, Methods and Techniques, Scope, rigor, complexity and Project perspective, Agile lifecycle Processes and the Funnel model of Agile UX. (Chapter - 3) The nature of UX design, Bottom up versus Top-down Design, Generative Design : ideation, sketching, critiquing, Prototype candidate design. (Chapter - 4) UX Evaluation Methods and Techniques Empirical UX evaluation : UX goals, metrics and Targets, Analytic UX evaluation : Data collection methods and Techniques. (Chapter - 5) Connecting Agile UX with Agile Software Engineering (Chapter - 6) wwTABLE OF CONTENT Chapter-1 Agile Development (1-1) to (1-42) 1.0 Introduction... 1-2 1.1 Agile Practices . 1.1.1 Agile Alliance. 1.1.1.1 Individuals and Interactions over Processes and Tools 1.1.1.2 Working Software over Comprehensive Documentation 1.1.1.3 Customer Collaboration aver Contract Negotiation. 1.1.1.4 Responding to Change over Following a Plan... 1.1.2 Principles... 1.13 Conclusion 1.2 Overview of Extreme Programming... 1.2.1 Customer Team Member. 1.2.2 User Stories 1.23 Short Cycles 1.2.3.1 Iteration Plan. 1.2.3.2 Release Plan .. 1.2.4 Acceptance Tests. 1.2.5 Pair Programming. 1.2.6 Test - Driven Development. 1.2.7 Collective Ownership. 1.2.8 Continuous Integration ... 1.2.9 Sustainable Pace. 1.2.10 Open Workspace. 1.2.11 Planning Game... 1.2.12 Simple Design.. 1.2.13 Refactorin 1.2.14 Metaphor w1.2.15 Conclusion 1.3 Planning... 1.3.1 Initial Exploration .. 1.3.1.1 pi ing, Splitting and Velocit 1.3.2 Release Planning 1.33 Iteration Planning... 1.3.4 Task Planning 1.3.4.1 Halfway Point 1.355 Iterating. 1.3.6 Conclusion... 1.4 Testing. 1.4.1 Test Driven Development. 1.4.1.1 Example of Test-First Desig 1.4.1.2 Test Isolation 1.4.1.3 Serendipitous Decoupl 1.4.2 Acceptance Tests... 1.4.2.1 Example of Acceptance Testing.. 1.4.2.2 Serendipitous Architecture 1.4.3 Conclusion 1.5 Refactoring... 1.5.1 Generating Primes : A Simple Example of Refactoring .. 1.5.1.1 The Final Reread... 1.5.2 Conclusion 1.6 Review Questions... ~1-42 Chapter-2 Agile Design (2 - 1) to (2-70) 2.1 What is Agile Design ?. 8 2.1.1 What Goes Wrong When it Comes to Software ?. -2 2.1.2 Design Smells... 2-2 2.1.2.1 What Causes Software to Degrade ?.. -6 2.2 Agile Teams Don't Let Software Degrade... -6 (wi)2.1.3 “Copy” Program. 2.1.3.1 Initial Design 2.1.3.2 Changing Requirements .. 2.1.3.3 Expect Changes. 2.1.3.4 Agile Design of the Copy Program.. 2.1.3.5 How Did the Agile Developers Know What to Do ?.. 2.1.4 Maintaining the Best Possible Design . 2.2 SRP : The Single - Responsibility Principle... 2.2.1 What is a Responsibility 2. 2.2.2 Separating Coupled Responsibilities 2.2.3 Persistence .. 2.3 OCP : The Open - Closed Principle... 2.3.1 Description .. 2.3.2 Abstraction is the Key... 2.3.3 Shape Application. 2.3.3.1 Violating the OCP.. 2.3.3.2 Bad Design. 2.3.3.3 Conforming to the OCP 2.3.3.4 Natural Structure and Anticipation 2.3.3.5 Safeguarding against Changes. 2.3.3.6 Stimulating Chang 2.3.3.7 Using Abstraction to Gain Explicit Closure 2.3.3.8 Using a Data-Driven Approach to Achieve Closure .. 2.4 LSP : The Liskov Substitution Principle .. 2.4.1 Simple Example of a Violation of the LSP... 2.4.2 Square and Rectangle, a More Subtle Violation... 2.4.2.1 Real Problem 2.4.2.2 Validity is not Intrins 2.4.2.3 ISA is about Behavior 2.4.2.4 Design by Contract (vid)2.4.2.5 Specifying Contracts in Unit Tests 2.4.3 Real Example. 2.4.3.1 Motivation 2.4.3.2 Problem 2.4.3.3 Solution that does not Conform to the LSP. 2.4.3.4 LSP-Compliant Solution 2.4.4 Factoring Instead of Deriving 2.4.5 Heuristics and Conventions. 2.4.5.1 Degenerate Functions in Derivatives. sotstnsnssneseesnnnnnes2 ~ 46 2-46 2.4.5.2 Throwing Exceptions from Derivatives su. 2.5 DIP : The Dependency - Inversion Principle . 2.5.1 Layering 2.5.1.1 Inversion of Ownership 2.5.1.2 Depend on AbStractiOns sesesseneanesnetnsetnetnsssa 2.5.2 Simple Example 2.5.2.1 Finding the Underlying Abstraction. 2.5.3 Furnace Example. 2.5.3.1 Dynamic Vs. Static Polymorphism. 2.6 ISP : The Interface - Segregation Principle 2.6.1 Interface Pollution 2.6.2 Separate Clients Mean Separate Interfaces. 2.6.2.1 The Backwards Force Applied by Clients on Interfaces. 2.6.3 ISP : The Interface - Segregation Principle 2.6.4 Class Interfaces Vs. Object Interfaces 2.6.4.1 Separation through Delegation 2.6.4.2 Separation through Multiple Inheritances .. 2.6.5 ATM User Interface Example.. 2.6.5.1 Polyad Vs. the Monad. 2.7 Review Questions. (viii)Chapter-3 UX and UX Design @- 1) to (3-64) 3.1 UX and UX Design .. 13-2 3.1.1 Expanding Concept of Interaction. 3.1.2 Definition of UX 3.1.2.1 Distinction from “Ur” 3.122 ‘inction from “HCI” . 3.1.2.3 What Does “UX” Mean ? 3.1.2.4 Rise of UX .... 3.1.2.5 What is User Experience ?. 3.1.3 UX Design 3.1.3.1 Can a User Experience be Designed ? . 3.1.3.2 Importance of UX Design. 3.1.4 Components of UX .. 3.1.4.1 An Analogy with Fine Di 3.1.4.2 Usability. 3.1.4.3 Usefulness... 3.1.4.4 Emational impact. 3.1.4.5 Meaningfulness .. 3.1.5 What UX is Not ?. 3.1.5.1 Not Dummy Proofing or User Friendliness. 3.1.5.2 Not Just About Dressing jings Up ina Pretty Skin 3.1.5.3 Not Just a Diagnosti 3.1.6 Kinds of Interaction and UX. 3.1.6.1 Localized Interaction 3.1.6.2 Activity-Based interaction 3.1.6.3 System-Spanning Interaction 3.1.6.4 The Dagstuhl Framework of Interaction and UX 3.1.7 Service Experience... 3.2 Wheel : UX Processes, Lifecycles, Methods, and Techniques. (oo3.2.1 INTRODUCTION 3.2.1.1 Where are we Heading ? 3.2.1.2 Need for Process 3.2.1.3 What do You Get by having a Process ? 3.2.2 Basic Process Components for UX. 3.2.2.1 UX Design Lifecycle 3.2.2.2 UX Lifecycle Activities, 3.2.2.3 UX Design Lifecycle Process. 3.2.2.4 Wheel : A Madel of the UX Lifecycle 3.2.2.5 Lifecycle Subactivities..susesssesneneanaeee 3.2.2.6 UX Method: 3.2.2.7 UX Technique 3.2.2.8 A Hierarchy of Term: 3.2.3 Fundamental UX Lifecycle Activities ... 3.2.3.1 Understand Needs UX Lifecycle Activity. 3.2.3.2 The Design Solutions UX Lifecycle Activity... 3.2.3.3 Prototype Candidates UX Lifecycle Activi 3.2.3.4 Evaluate UX Lifecycle Activity 3.2.4 UX Design Techniques as Life Skills . 3.2.4.1 Observation. 3.2.4.2 Abstraction... 3.2.4.3 Note Taking 3.2.4.4 Data / Idea Organization 3.2.4.5 Modeling .. 3.2.4.6 Storytelling .. 3.2.4.7 Immersion nnssesnens3 32 3.2.4.8 Brainstorming ssn 3.2.4.9 Sketching and Drawing. 3.2.4.10 Framing and Reframing -1..c.snssssesnssnnsisennssnensensnie 3.2.4.11 Reasoning and Deduction. 3.2.4.12 Prototyping and Envisioning. Co)3.2.4.13 Critical Thinking 3.2.4.14 Iteration.. 3.2.4.15 UX Techniques are used in Combinatior 3.3 Scope, Rigor, Complexity and Project Perspectives 3.3.1 Introduction. 3.3.1.1 Rigor and Seope : Project Parameters that Determine Process Choices 3.3.2 Rigor in a UX Method or Proces: 3.3.2.1 What Is Rigor ? . 3.3.2.2 Complexity as an Influence on the Need for Rigo 3.3.2.3 Domain Familiarity as an Influence on the Need for Rigor. 3.3.2.4 Risk Aversion Influences the Need for Rigor .. 3.3.2.5 Stage of Development within Your Project as an Influence on the Need for Rigor 3.3.2.6 Project Resources. 3.3.2.7 Being Rapi fecycle Activities, Methods and Techniques. 3.2.3 Scope of Delivery. 3.3.4 Commercial Product Perspective and Enterprise System Perspective 3.3.4.1 Commercial Product Perspective .. 3.3.4.2 Enterprise System Perspective. 3.4 Agile Lifecycle Processes and the Funnel Model of Agile UX. 3.4.1 Challenges in Building Systems 3.4.1.1 Change Happens During a Project. 3.4.1.2 Two Views of These Changes 3.4.1.3 Gap Between View: 3.4.1.4 Responding to Change. 3.4.1.5 Closing the Gay 3.4.1.6 True Usage is the Only Ascertainer of Requirements. 3.4.2 Old Waterfall SE Lifecycle Process. 3.4.2.1 Waterfall Process was an Early SE Attempt to Get Organized .uscssnssee 3.4.2.2 Waterfall Process did have Some Feedback, but Not the Right 3.4.3 Embracing an Agile Lifecycle Process.. (xi)3.4.3.1 Scope and Chunking are Key to Real Usage Feedback 3.4.3.2 Having Measure of Agility without Chunking. 3.4.3.3 SE Team and User-facing Prototypes 3.4.3.4 SE Team not interested in Users. 3.4.3.5 Why UX followed SE into an Agile Approach 3.4.4 The Funnel Model of Agile UX. 3.4.4.1 Why a New Model was Needed ?. 3.4.4.2 Introducing the Funnel Model of Agile UX .. 3.4.4.3 Late Funnel Activiti st nsesnies3 ~ 60 3-63 3.4.4.4 Early Funnel Activities sess 3.5 Review Questions. Chapter-4 Nature of UX Design (4- 1) to (4 - 62) 4.1 Nature of UX design 4-2 4.1.1 Introduction... 4-2 4.1.1.1 Mowing across the Gap from Analysis to Design -2 4.1.1.2 Universality of Design and Relationship to Other Fields -2 4.1.1.3 Relationship to Design in Architecture. 4.1.1.4 Interdisciplinary Nature of Design. 4.1.2 Whats Design.. 4.1.2.1 Two Ways the Word "Design' is Used. 4.1.3 Purpose of Design. 4.1.3.1 Pyramid of Human Needs. 4.1.4 Information, Information Design and Information Architecture .. 4.1.4.1 What is Information ?. 4.1.4.2 Information Science 4.1.4.3 Information Architecture, 4.1.4.4 Pervasive Information Architecture .. 4.1.4.5 Information Design 4.155 Iteration in the Design Creation Sublifecycle . 4.15.1 Deciding on the Design Geal .. i)4.1.5.2 Generative Design Iteration ... 4.15.3 Conceptual Design Iteration. 4.15.4 Intermediate Design iteration 4.15.5 Detailed Design Iteration, 4.1.5.6 Design Refinement iteration .. 4.15.7 SE Implementation 4.1.5.8 UX Compliance Phase 4.1.6 Design Lifecycle for the Agile UX Funnel 4.2 Bottom - up Versus Top - down Design... 4.2.1 Introduction. 4.2.2 Bottom - up Design. 4.2.2.1 Recap of our Process Steps thus Far. 4.2.2.2 Process so far is Bottom Up. 4.2.2.3 Human - centered Design or User-centered Design: Common Names for Bottom - up Design... 4.2.2.4 Designing for Existing Work Practice is Practica 4.2.2.5 Role of Biases and Constraints 4.2.3 Abstract Work Activities 4.2.3.1 Nature of Wark and Work Practice 4.2.3.2 Abstract Work Activity. 4.2.3.3 Work Activity Instances 4.2.3.4 Importance to Start Top - down Design with Abstract Work Aetivitie 4.2.4 Top - down De 4.2.4.1 Top - down Design Goa! 4.2.4.2 Characteristics of Top - down Design .sssssestnssene 4.2.4.3 Top - down Design is not Always Practical .. 4.2.4.4 Easing the Transition for Customers and Users. 4.2.4.5 Extreme Top - down Design ... 4.3 Generative Design 4.3.1 Introduction. 4.3.1.1 Preparing for Design Creation : ImMeFSion ...u:ssssesseneinnenesnesies (ii)4.3.1.2 Role of Synthesis 4.3.1.3 Overview of Generative Design.. 4.3.2 ideation 4.3.2.1 Creative Role of Ideation in Design 4,3.2.2 Ideas : The Building Blocks of Design. 4.3.2.3 ideation Scope. 4.3.2.4 ideation informers, Catalysts and Techniques 4.3.2.5 Doing ideation. 4.3.2.6 ideation informers sesttnusennesientnnnnsensesneed 7 36 4.3.2.7 Ideation Catalysts ssn 4.3.2.8 Ideation Techniques .. 4-36 4.3.3 Sketching 4.3.3.1 Characteri of Sketching 4.3.3.2 Doing Sketching .. 4.3.3.3 Physical Mockups as Embodied Sketches 4.3.4 Critiquing 4.3.4.1 Include Users in the Critiquing Activity ...0.isuesnenennensnesnenie 4.4 Prototype Candidate Designs 4.4.1 Introduction. 4.4.1.1 Prototyping Intertwines with Other UX Activities. 4.4.1.2 Dilemma and a Soluti 4.4.1.3 Advantages of Prototyping.. 4.4.1.4 Universality of Prototyping. 4.4.2 Depth and Breadth of a Prototype 4.4.2.1 Horizontal Protatypes sess 4.4.2.2 Vertical Prototypes 4.4.2.3 LOCAl Prototypes wnssssuese 4.4.2.4°T" Prototypes. 4,43 Fidelity of Protatypes 4.4.4 Wireframe Prototypes... (iv)4.4.4.1 What is a Wireframe ? sense 4.4.4.2 Wireframe Design Elements. 4.4.4.3 Wireflow Prototypes 4.4.4.4 General Process of Representing Interaction. 4.4.4.5 Create a Wireframe for Each State sisi 4.45 Build up Prototypes in Increasing Levels of Fidelity. 4.4.5.1 High - level Task Context 4.45.2 Very Low - fidelity Wireframe Sketches 4.4.5.3 Static Low - fidelity Wireframes 4.4.5.4 Increased Fidelity Wireframes. 4.4.5.5 Medium - fidelity Wireframes with Some Navigational Behavior. 4.4.5.6 Medium - to High - fidelity Click - through Prototypes 4.4.5.7 Medium - to High - fidelity Prototypes. 4.4.6 Specialized Prototypes. 4.4.6.1 Physical Mockups for Physical Interactivity 4.4.6.2 Paper - in- device Mockup Prototype wets 4.4.6.3 Animated Prototypes 4.4.6.4 Experi \¢e Prototyping, the Goal of High - fidelity Phy | Prototyping 4.4.7 Software Tools for Making Wireframes 4.5 Review Questions. Chapter-5 UX Evaluation Methods and Techniques (5 - 1) to (5 - 50) 5.1 UX Evaluation Methods and Techniques .. 5-2 5.1.1 Introduction. 5.1.1.1 Methods versus Techniques... 5.1.1.2 Types of UX Evaluation Data . 5.1.1.3 Formative Evaluation versus Summative Evaluation. 5.1.2 UX Evaluation Methods. 5.1.2.1 Empirical UX Evaluation Methods 5.1.2.2 Analytic UX Evaluation Methods wu. 5.1.2.3 Comp: in 7 5.1.2.4 Some Specific Empirical UX Evaluation Methods .u.ususenesnennsenernnenS “B wv)5.1.2.5 Weaknesses of UX Evaluation Methods. 5.1.2.6 Some Specific Analytic UX Evaluation Methods ... 5.1.3 Rigor vs Rapidness in UX Evaluation Methods and Techniques. 5.1.3.1 Tradeoff between Rapidness and Achievable Rigor. 5.1.3.2 Range of Rigor and Speed 5.1.3.3 Methods to Favor Rapidness over Rigor . 5.1.4 UX Evaluation Data Collection Techniques .. 5.1.4.1 Quantitative Data Collection Techniques. 5.1.4.2 Qualitative Data Collection Techniques .. 5.1.5 Specialized UX Evaluation Methods... 5.1.5.1 Alpha and Beta Testing and Field Surveys. 5.1.5.2 Remote UX Evaluation.. 5.1.5.3 Automatic UX Evaluation. 5.1.6 Adapting and Appropriating UX Evaluation Methods and Techniques. 5.2 Empirical UX Evaluation : UX Goals, Metrics, and Target: 5.2.1 Introduction. 5.2.1.1 Project Context for UX Metrics and Targets. 5.2.2 UX Target Tables 5.2.3 Work Role and User Classes... 5.2.4 UX Goals. 5.2.5 UX Measures .. 5.2.6 Measuring Instruments : Benchmark Tasks 5.2.6.1 What is a Benchmark Task ?... 5.2.6.2 Selecting Benchmark Tasks 5.2.6.3 Crafting Benchmark Task Contents wes ities eects ~26 5.2.7 Measuring Instrument : User Satisfaction Questionnaires 5-28 5.2.8 UX Metrics... -5-30 5.2.9 Baseline Level -32 5.2.10 Target Level. ne 5-32 5.2.11 Setting Level -32 wi)5.2.1.1 Setting the Baseline Level. 5.2.11.2 Setting the Target Level. 5.2.12 Observed Results. 5.3 Analytic UX Evaluation : Data Collection Methods and Techniques .. 5.3.1 Introduction. 5.3.1.1 Adding Analytic Methods to the Mix 5.3.1.2 Criticism of Analytic Methods 5.3.2 Design Walk - Throughs and Reviews. 5.3.2.1 Design Walk - Throughs 5.3.2.2 Design Reviews 5.3.2.3 Prepare for a Design Review 5.3.2.4 Conduct a Design Review Session 5.3.3 Focus Groups. 5.3.4 Expert UX Inspection. 5.3.4.1 What is UX Inspection 2. 5.3.4.2 Inspection is a Valuable Tool in the UX Toolbox. 5.3.4.3 How Many Inspectors are Needed ? 5.3.4.4 What Kind of Inspectors are Needed ?. 5.3.5 Heuristic Evaluation, a UX Inspection Method. 5.3.5.1 Introduction. 5.3.6 Practical Approach to UX Inspectior 5.3.6.1 Guided by Insight arid Experience. 5.3.6.2 Use a Codiscovery or Team Approach in UX Inspection.. 5.3.6.3 Explore Systematically with a Rich and Comprehensive Usage - Oriented VieW...nssutsnesse 5.3.6.4 Inspection is Driven by Tasks and by the Design Itself 5.3.6.5 Analytic UX Evaluation in the Layers of the Needs Pyra 5.3.6.6 Ecological - Layer Inspection .. 5.3.6.7 Intera n- Layer inspection. 5.3.6.8 Emotional - Layer Inspection .. 5.4 Review Questions... (xvi)Chapter-6 Connecting Agile UX with Agile Software Engineering (6 - 1) to (6 - 22) 6.1 Introduction. 6.2 Basics of Agile SE Method ... 6.2.1 Goals and Principles of Agile SE. 6.2.2 Goals and Principles of Agile SE.. 6.2.2.1 Operating in Silos.. 6.2.3 Characteristics of Agile SE Methods 6.2.3.1 Avoiding Big Design Upfront 6.3 Lifecycle Aspects of Agile SE.. 6.3.1 Planning in Agile SE Methods. 6.3.1.1 Customer Stories... 6.3.1.2 Story - Based Planning 6.3.1.3 Managing Customer Stories and Development Tasks. 6.3.1.4 Controlling Seope 6.3.2 Sprints in Agile SE Methods. 6.3.2.1 Acceptance Test Creation 6.3.2.2 Unit Code Test Creation .. 6.3.2.3 Implementation Coding. 6.3.2.4 Code Testing.. 6.3.2.5 Regression Testing, 6.3.2.6 Acceptance Testing and Deployment. 6.3.3 Sprints in Agile SE Methods... 6.4 Challenges of Agile SE Methods from the UX Perspective 6.5 What is Needed on the UX Side ? .. 6.6 Problems to Anticipate 6.6.1 UX and SE Collaboration. 6.6.2 Need for a Full Overview. 6.7 Synthesized Approach to Integrating Agile UX and Agile SE.. 6.7.1 Integrating UX into Planning .6.7.1.1 Small Upfront Analysis and Design. 6.7.1.2 UX Role Helps Customer Write User Stories . 6.7.1.3 Truth about User Stories 6.7.1.4 UX Role Helps Customer Prioritize User Stories 6.7.2 Integrating UX into Sprints. 6.7.3 Synchronizing Two Agile Workflows 6.7.3.1 Dove - Tailed Work Activities.. 6.7.3.2 Value of Early Delivery. 6.7.3.3 Continuous Delivery... 6.7.3.4 Importance of Regression Testing... 6.7.3.5 Planning across Iterations 6.7.3.6 Communication during Synchronization. 6.8 Review Questions. 6a)Notes boo)Agile Development Syllabus Agile Practices, Overview of Extreme Programming, Planning, Testing, Refactoring. Contents 1.0 Introduction 1.1 Agile Practices 1.2 Overview of Extreme Programming 1.3 Planning 1.4 Testing 1.5 Refactoring 1.6 Review Questions a9Agile Development and UI/ UX Design 1-2 Agile Development EE introduction Principles, patterns and practices are significant, but it’s the people that mark them effort. As Alistair Cockburn says, 1 “Process and technology are a second-order conclusion on the outcome of a project. The first-order conclusion is the people.” We cannot cope teams of programmers as if they were systems made up of components driven by a process. People are not “plug-compatible programming units."2 If our projects are to flourish, we are going to have to construct collective and self-organizing teams. Those companies that inspire the formation of such teams will have an enormous competitive advantage over those who hold the view that a software-development organization is nothing more than a mountain of twisty little people all alike. EE Agile Practices The absence of effective practices in project leads to impulsiveness, repeated error and wasted effort. Customers are dissatisfied by slipping schedules, increasing budgets and poor quality. Developers are discouraged by working ever longer hours to yield ever poorer software. Once we have practiced such a fiasco, we become frightened of repeating the experience. Our fears encourage us to create a process that constrains our activities and stresses certain outputs and artifacts. We appeal these constraints and outputs from past experience, selecting things that appeared to work healthy in previous projects. Our hope is that they will work again and take away our doubts. However, projects are not so modest that a rare constraints and artifacts can dependably avoid error. As errors continue to be made, we identify those errors and put in place even more constraints and artifacts in order to avoid those errors in the future. After many, projects we may find ourselves loaded with a huge awkward process that greatly obstructs our ability to get anything done. A big awkward process can create the very difficulties that itis designed to avoid. It can slow the team to the degree that schedules slip and budgets swell. It can diminish responsiveness of the team to the point where they are always creating the incorrect product. Inappropriately, this leads many teams to believe that they don’t have sufficient process. So, in a kind of runaway-process increase, they make their process ever larger. TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-3 Agile Development EKEI Agile Alliance © A group of industry professionals met in early 2001, inspired by the observation that software teams in many organizations were stuck in a maze of ever-increasing process, to describe the values and principles that would allow software teams to operate fast and respond to change. They called themselves the Agile Alliance. They spent the following few months putting together a statement of values. The Agile Alliance's Manifesto was the result. The Manifesto of the Agile Alliance Manifesto for Agile Software Development We are revealing 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 ividuals and Interactions over Processes and Tools * People are the most vital ingredient of success. A decent process will not save the project from failure if the team doesn’t have solid players, but a corrupt process can make even the solidest of players unproductive. Even a group of strong players can fail severely if they don’t work as a team. + A solid player is not inevitably a first-rate programmer. A solid player may be a normal programmer, but someone who works well with others. Working well with others, cooperative and interacting, is more important than raw programming talent. A team of regular programmers who communicate well are more likely to thrive than a group of superstars who fail to interact as a team. © The correct tools can be very imperative to success. Compilers, IDEs, source-code control systems, etc. are all vital to the correct functioning of a team of developers. However, tools can be exaggerated. An excess of big, cumbersome tools is just as bad asa lack of tools. * Remember, building the team is more vital than building the environment. Many teams and managers make the blunder of building the environment first and TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-4 Agile Development guessing the team to gel automatically. In its place, work to create the team and then let the team organize the environment on the basis of need. EREEJ Working Software over Comprehensive Documentation + Software without documentation is a tragedy. Code is not the perfect medium for communicating the rationale and structure of a system. Somewhat, the team needs to produce human-readable documents that define the system and the rationale for their design decisions. + However, too much documentation is worse than not enough. Massive software documents require a long time to create and considerably longer to maintain in syne with the code. If they are not kept in sync, then they turn into huge, complex lies and become a substantial source of misdirection. « Itis always a good idea for the team to write and preserve a rationale and structure document, but that document requires to be small and salient. By “short,” I mean one or two dozen pages at most. By “salient,” I mean it should discuss the complete design rationale and only the highest-level structures in the system. « The two documents that are the greatest at transferring information to new team members are the code and the team. The code does not falsehood about what it does. It may be hard to extract rationale and intent from the code, but the code is the only unmistakable source of information. The team members grasp the ever- changing road map of the system in their heads. There is no quicker and more efficient way to transfer that road map to others than human to human communication. ¢ Many teams have grown suspended up in the chase of documentation instead of software. This is frequently a fatal flaw. There is a simple rule called Martin’s first law of documentation that avoids it : Produce no document unless its need is immediate and significant. EERE] customer Collaboration over Contract Negotiation Software is not a commodity that can be bought and sold. You can't create a representation of the software you want and then have it developed on a certain schedule for a set price. Attempts to treat software projects in this manner have often failed. The failures might be spectacular at times. © It is alluring for the managers of a company to say their development staff what their needs are and then think that staff to go away for a while and return with a system that pleases those needs. However, this mode of operation hints to poor quality and failure. TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-5 Agile Development Successful projects contain customer feedback on a consistent and frequent basis. Rather than contingent on a contract or a statement of work, the customer of the software works thoroughly with the development team, providing regular feedback on their efforts. A contract that stipulates the requirements, schedule and cost of a project is essentially flawed. In most cases, the terms it specifies become worthless long before the project is completed. The best contracts are those that govern the way the development team and the customer will work together. EERE] Responding to Change over Following a Plan * Itis the ability to react to change that frequently determines the success or failure of a software project. When we build plans, we need to make sure that our plans are flexible and ready to adjust to changes in the business and technology. + The course of a software project cannot be scheduled very far into the future. First of all, the business environment is likely to change, producing the requirements to shift. Second, customers are expected to alter the requirements once they see the system start to function. Finally, even if we recognize the requirements and we are sure they won't change, we are not very good at guessing how long it will take to develop them. « Itis alluring for trainee managers to create a nice PERT or Gantt chart of the whole project and tape it to the wall. They may sense that this chart gives them control over the project. They can track the individual tasks and cross them off the chart as they are finished. They can compare the actual dates with the planned dates on the chart and respond to any discrepancies. «What really happens is that the structure of the chart damages ? As the team gains knowledge about the system, and as the customers gain knowledge about their needs, certain tasks on the chart become pointless. Other tasks will be exposed and will need to be added. In short, the plan will undergo changes in shape, not just changes in dates. « An improved planning strategy is to make detailed plans for the next two weeks, very coarse plans for the next three months and enormously crude plans beyond that. We should know the tasks we will be working on for the next two weeks. We should coarsely know the requirements we will be working on for the next three months. And we should have only an imprecise idea what the system will do after a year. TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-6 Agile Development ERE4 Principles © The above values motivated the following 12 principles, which are the characteristics that distinguish a set of agile practices from a heavyweight process : © Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. o The MIT Sloan Management Review published an analysis of software development practices that help companies construct high-quality products. The article found a number of practices that had a significant influence on the quality of the final system. One practice was a strong association between quality and the early delivery of a moderately functioning system. The article reported that the less functional the initial delivery, the higher the quality in the final delivery. o An agile set of practices delivers early and often. We struggle to deliver a fundamental system within the first few weeks of the start of the project. Then, we try to continue to deliver systems of increasing functionality every two weeks. o Customers may pick to put these systems into production if they reason that they are functional adequate. Or they may choose simply to review the current functionality and report on changes they need made. * Changes in requirements are welcome, especially if they occur late in the development process. Agile methods facilitate change for the benefit of the customer’s competitive position. o This is an attitude statement. In an agile process, participants are not afraid of change. They see modifications in the specifications as positive since it means the team has gained a better understanding of what it will take to delight the market. © When needs change, an agile team works very hard to maintain the structure of its software adaptable so that the impact on the system is low. # Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the tinier time scale. © We deliver working software and we delivery it early and frequently. We are not content with delivering packets of documents or plans. We don’t count those as real deliveries. Our eye is on the goal of delivering software that satisfies the customer's needs. Business people and developers must work together every day throughout the project. © Customers, developers and stakeholders must have regular and meaningful TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-7 Agile Development interactions in order for a project to be agile. A software project isn't like a weapon that you shoot and forget about. A software project must be guided indefinitely. Build projects around people who are passionate about what they're doing. Give them the environment and support they require, and trust them to do the task. o A project that is agile considers people to be the most crucial aspect in its success. © All other factors - process, environment, management, etc. - are measured to be second order effects and they are subject to change if they are having a contrary effect upon the people. e For example, if the office environment is an obstacle to the team, the office environment must be changed. If certain process steps are an obstacle to the team, the process steps must be changed. * The most efficient and effective method of assigning information to and within a development team is face-to- face conversation. o In anagile project, people talk to each other. The main mode of communication is conversation. Documents may be created, but there is no effort to capture all Project information in writing. An agile project team does not claim written specs, written plans or written designs. Team members may create them if they notice an immediate and significant need, but they are not the default. The default is conversation. Working software is the prime measure of progress. o Agile projects measure their progress by measuring the amount of software that is presently meeting the customer’s need. They don’t measure their progress in terms of the phase that they are in or by the volume of documentation that has been produced or by the amount of infrastructure code they have created. They are 30 % done when 30 % of the required functionality is working. «Agile processes support long-term development. Sponsors, developers and consumers should all be able to keep up a steady pace indefinitely. © An agile project is not run like a 50-yard dash; it is run like a marathon. The team does not lift off at full speed and attempts to maintain that speed during the duration. Rather, they move at a quick yet steady speed. o Burnout, shortcuts and disaster are all consequences of going too fast. Agile teams work at their own speed. They don't let themselves become too exhausted. They don't spend tomorrow's energy in order to get a little more done today. TECHNICAL PUBLICATIONS® - an up-thnust for knowiedgeAgile Development and UI/ UX Design 1-8 Agile Development They operate at a pace that allows them to retain the highest level of quality throughout the project. © Aconstant focus on technical excellence and smart design improves agility. ° The importance of great quality above rapid speed cannot be overstated. Keeping the software as clean and healthy as possible is the fastest way to progress. Asa result, every member of the agile team is dedicated to generating only the finest quality code possible. They don't make mistakes and then convince themselves that they'll fix it when they have more time. If they make a chaos, they clean it up before they finish for the day. Simplicity - The art of exploiting the amount of work not done is crucial. ° Agile teams do not try to build the magnificent system in the sky. Rather, they always take the simplest path that is reliable with their goals. They don’t put a lot of importance on antedating tomorrow's problems, nor do they try to defend against all of them today. Instead, they do the simplest and highest-quality work today, confident that it will be easy to change if and when tomorrow's problems ascend. The best architectures, requirements and designs arise from self-organizing teams, ° An agile team is a self-organizing team. Individual team members are not given responsibilities from the outside. Responsibilities are conveyed to the entire team, and the team decides how best to carry them out. Members of the agile team collaborate on all aspects of the project. Each person is allowed to contribute to the whole. No one in the team is responsible for the architecture, requirements, or tests. These tasks are shared by the team and each team member has influence over them. ‘At regular intervals, the team echoes on how to become more effective, then refrains and adjusts its behaviour accordingly. ° An agile team repeatedly adjusts its organization, rules, conventions, relationships, etc. An agile team knows that its environment is unceasingly changing and knows that they must change with that environment to persist agile. EEE conctusion * The professional goal of every software developer and every development team is to deliver the uppermost possible value to their employers and customers. And yet TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-9 Agile Development our projects fail or fail to bring value, at a horrifying rate. Though well intentioned, the ascendant spiral of process inflation is responsible for at least some of this failure. Agile software development principles and values were developed to assist teams in breaking the cycle of process inflation and focusing on basic strategies for achieving their objectives. EE} Overview of Extreme Programming Extreme programming is the most well-known of the agile methods. It is made up of a set of simple, yet co-dependent practices. These practices work together to form a whole that is greater than its parts. Customer Team Member We want the customer and developers to work closely with each other so that they are both aware of each other's problems and are working together to resolve those problems. © Customers are the individual or group who describes and prioritizes features is the client of an XP team. « The customer is sometimes a team of business analysts or marketing experts who work for the same organization as the engineers. The customer is sometimes a user representative appointed by the user body. Sometimes the paying customer is the customer. In an XP project, however, the clients are members of the team and are available to them. * The top case is for the customer to work in the same room as the developers. Next best is if the customer works in within 100 feet of the developers. The superior the distance, the tougher it is for the customer to be a true team member. If the customer is in another building or another state, it is very tough to integrate him or her into the team. * It is recommended to find someone who can be close by and who is eager and able to stand in for the true customer. User Stories © Inorder to plana project, we must know something about the requirements, but we don’t need to know very much. * For planning purposes, we only want to know enough about a requirement to guess it. You may think that in order to estimate a requirement you need to know all its details, but that’s not relatively true. You have to know that there are details and TECHNICAL PUBLICATIONS® - an up-thnust for knowiedgeAgile Development and UI/ UX Design 1-10 Agile Development you have to know coarsely the kinds of details there are, but you don’t have to know the particulars. * The specific details of a requirement are likely to change with time, particularly once the customer initiates to see the system come together. There is nothing that emphases requirements better than seeing the embryonic system come to life. Therefore, seizing the specific details about a requirement long before it is implemented is likely to result in unused effort and impulsive focusing. * When using XP, we get the sense of the details of the requirements by talking them over with the customer, but we do not seizure that detail. Rather, the customer writes a few words on an index card that we agree will prompt us of the conversation. The developers write an estimate on the card at coarsely the same time that the customer writes it. They base that estimate on the sense of detail they got during their conversations with the customer. © A.user story is a mnemonic token of an ongoing conversation about a requirement. It is a planning instrument that the customer uses to schedule the implementation of a requirement based upon its priority and estimated cost. Short Cycles Every two weeks, an XP project delivers working software. Each of these two-week iterations results in working software that addresses part of the stakeholders’ requirements. The system is presented to the stakeholders at the end of each iteration in order to obtain feedback. E28 tteration Pian © An iteration lasts about two weeks on average. It's a little delivery that might or might not be put into production. It's a collection of user stories chosen by the client within the parameters of a budget set by the developers. * The budget for an iteration is determined by the amount of work completed in the previous iteration. The customer may choose any number of stories for the iteration, so long as the total of their estimates does not surpass that budget. * Once an iteration has been started, the customer approves not to change the definition or priority of the stories in that iteration. During this time, the developers are free to censor the stories up in to tasks and to develop the tasks in the order that makes the best technical and business sense. TECHNICAL PUBLICATIONS® - an up-thnust for knowledgeAgile Development and UI/ UX Design 1-14 Agile Development FEZ 2] release Pian © XP teams often create a release plan that plans out the next six iterations or so. That plan is known as a release plan. A release is usually three months’ worth of work. It characterizes a main delivery that can usually be put into production. A release plan entails of prioritized collections of user stories that have been selected by the customer conferring to a budget given by the developers. The developers set the budget for the release by measuring how much they got done in the preceding release. The customer may choose any number of stories for the release so long as the total of the estimates does not surpass that budget. The customer also governs the order in which the stories will be implemented in the release. If the team so desires, they can map out the first few iterations of the release by displaying which stories will be completed in which iterations. * Releases are not cast in stone. The customer can change the content at any time. He or she can abandon stories, write new stories, or change the precedence of a story. Acceptance Tests * The client specifies acceptance tests in which the details of the user stories are collected. Acceptance tests for a narrative are prepared soon before or even simultaneously with, the story's implementation. They are written in a scripting language that allows them to be executed repeatedly and automatically. They work together to ensure that the system is performing as the consumers have requested. The language of the acceptance tests grows and advances with the system. The customers may recruit the developers to create a simple scripting system, or they may have a discrete Quality Assurance (QA) department that can develop it. Many customers solicit the help of QA in developing the acceptance-testing tool and with writing the acceptance tests themselves. Once an acceptance test passes, it is added to the body of passing acceptance tests and is never permitted to fail again. This growing body of acceptance tests is run numerous times per day, every time the system is built. If an acceptance tests fails, the build is acknowledged a failure. Thus, once a requirement is implemented, it is never broken. The system transitions from one working condition to the next and is never allowed to be defective for more than a few hours. Pair Programming * All production code is written by two programmers working at the same time on the same computer. Each pair has one person who operates the keyboard and types TECHNICAL PUBLICATIONS® - an up-thnust for knowledge