1. SOFTWARE RISK MANAGEMENT WITHIN AGILE ENVIRONMENTS GROUP #3 | KSK CHAITANYA | PIYUSH DESHPANDE | YOUSEF HADDAD

2. FIRST SEMINAR RECAP  Intro to Software Risk Management  Types of Risk Management  Agile vs Traditional processes of dealing with Risk  Risk Management processes that might risk loss of agility  How Agile Software Engineering mitigates some types of risk organically

3. SEMINAR OUTLINE  Technical Debt: Definition, types, causes and how to deal with it  Code Reviews  Code Analysis Tools  SonarQube  Agile Team Collaboration Platforms  Atlassian Jira, Microsoft VSTS

4. TECHNICAL DEBT DEFINITION, TYPES, CAUSES AND HOW TO DEAL WITH IT

5. TECHNICAL DEBT  Concept introduced in 1994 by Ward Cunningham  Also known as Design Debt or Code Debt.  It is often mentioned, rarely studied.  Drags long lived projects and products down.  Technical debt is a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution.

6. TECHNICAL DEBT – ORIGIN OF THE METAPHOR  According to Ward Cunningham  “Shipping first time code is like going into debt. A little debt speeds up development so long as it is paid back promptly with a rewrite. The danger occurs when the debt is not repaid. Every minute spent on not-quite-right code accounts as interest on that debt. Entire organizations can be brought to a standstill under the debt load of an unconsolidated implementation.”

7. CLASSIFYING TECHNICAL DEBT

8. INTENTIONAL VS UNINTENTIONAL TECHNICAL DEBT Intentional Debt  “If we don’t get this release done, there won’t be a second release.” (Rationale for cutting corners)  “We don’t have time to build in general support for multiple platforms. We’ll support iOS now and build in support for Android, etc., later.”  “We didn’t have time to write unit tests for all the code we wrote the last 2 months of the project. We’ll write those after we release.” Unintentional Debt  A junior programmer writes bad code.  A contractor writes code that doesn’t follow the coding standard  A major design strategy turns out poorly  Your company acquires a company that has a lot of technical debt  A comprehensive refactoring project goes horribly wrong

9. TECHNICAL DEBT AND REPAYMENT OVER SPRINT PROGRESSION

10. MANAGING TECHNICAL DEBT  To manage technical debt effectively, we need to : 1. Identify what debt you have 2. Make it visible for decision-making purposes 3. Decide what to do about it (for example, pay it off, live with it) 4. Implement changes to reduce or eliminate the effects of it

11. TECHNICAL DEBT  Signs of Technical Debt  Slowing Rate of Velocity  Stressful Releases  Defects  Finding and Resolving Technical Debt  Code Reviews, Tests, Code Analysis Tools  Managing Product Backlog to reflect repayment of debt

12. CODE REVIEWS DEFINITION

13. CODE REVIEW Code review is a special kind of inspection in which the team examines a sample of code and fixes any defects in it.  In a code review, a defect is a block of code which does not properly implement its requirements, which does not function as the programmer intended, or which is not incorrect but could be improved  For example, it could be made more readable or its performance could be improved. When a developer is finished working on an issue, another developer looks over the code and considers questions like:  Are there any obvious logic errors in the code?  Looking at the requirements, are all cases fully implemented?  Are the new automated tests sufficient for the new code? Do existing automated tests need to be rewritten to account for changes in the code?  Does the new code conform to existing style guidelines?

14. CODE REVIEW: BENEFITS  Code reviews share knowledge  Code reviews make for better estimates  Inclusion of new engineers and developers, providing mentorship  When done right, code reviews save time in the long run

15. CODE REVIEW CHECKLIST  Clarity  Is the code clear and easy to understand?  Can the code be refactored to make it clearer?  Maintainability  Will other programmers be able to maintain this code?  Is it well commented and documented properly?  Accuracy  Does the code accomplish what it is meant to do?  If an algorithm is being implemented, is it implemented correctly?  Readability and Robustness  Is the code fault-tolerant? Is the code error-tolerant?  Will it handle abnormal conditions or malformed input?  Security  Is the code vulnerable to unauthorized access, malicious use, or modification?  Scalability  C ould the code be a bottleneck that prevents the system from growing to accommodate increase load, data, users, or input?  Reusability  Could this code be reused in other applications?  Can it be made more general?  Efficiency  Does the code make efficient use if memory, CPU cycles, bandwidth, or other system resources?  Can it be optimized?

16. CODE REVIEW: BEST PRACTICES 1. Review fewer than 400 lines of code at a time. 2. Do not review for more than 60 minutes at a time 3. Set goals and capture metrics 4. Use checklists 5. Establish a process for fixing defects found. 6. Foster a positive code review culture. 7. Practice lightweight code reviews.

17. CODE ANALYSIS TOOLS SONARQUBE

18. STATIC PROGRAM ANALYSIS  Tools that review and analyze the program  Could run on source code (SonarQube) or on object code (FindBugs)  Can be included as a step within Continuous Integration  Can be integrated within IDEs (SonarLint for Eclipse and Visual Studio)  Provides metrics for the program including:  Bugs, potential bugs, issues, …  Code duplication analysis  Code coverage  Best practices that could be implemented  Code complexity/size  Inline comment analysis

19. Source: http://zeroturnaround.com/rebellabs/developers-guide-static-code-analysis-findbugs-checkstyle-pmd-coverity-sonarqube/2/

20. SONARQUBE  Developed at SonarSource  Currently at version 5.4  Can be installed on-premise or on cloud VM  Supports 20+ languages: C/C++, C#, Java, Javascript, PHP, Python, VB.NET, …  Pre Commit Analysis:  Has plugins to be integrated within an IDE (SonarLint)  Has plugins to be integrated within GitHub, BitBucket (SonarQube Stash)  Can be automated through Jenkins, TravisCI, MS Build, …  Integrates with JIRA for issue tracking  Easy access to historical data for metrics  Speaks in Technical Debt terms (issues/time)

21. SONARQUBE (CONTINUED)  All-in-One-Place analytics solution:  Multiple projects  Code duplication and number of duplicated blocks  Code size and complexity  Tracking issues  Blocker/Critical/Major/Minor/Info  Can be drilled down to code  Code Coverage  Differentials in measurements between tests  Customizable Quality Gates  Metrics can be provided in Technical Debt Time (minutes/hours/days)

22. DEMO: SONARQUBE

23. TEAM COLLABORATION PLATFORMS JIRA | VISUAL STUDIO TEAM SERVICES

24. TEAM COLLABORATION SYSTEMS  Systems that provide a workspace for teams to collaborate and communicate  Could be cloud-based or on-premise  Tracking and user assignment for Issues, Bugs, User Stories, Tasks, …  Customizable dashboards, reports and charts  Host and/or View source code repository  Provide automated tasks and Continuous Integration  Provide transparency and facilitate team communication

25. MICROSOFT VISUAL STUDIO TEAM SERVICES  Version Control:  Supports Git and TFVC  Unlimited private repositories  Agile Team Tools:  Issue/Bug/Backlog Item tracking  Kanban and Scrum dashboards  Links Work Items to code and branches  Continuous Integration and Deployment  Can be extended to use Jenkins instead  Extensibility: Market Place items, other tools available through REST APIs  Test tooling  Direct integration with Visual Studio and Eclipse  Free for up to 5 users! Notable Users

26. DEMO: VISUAL STUDIO TEAM SERVICES

27. ATLASSIAN JIRA  Open Source, launched in 2002  Web Based, cloud and on-premise  Manage, customize and assign work items: Issues, Bugs, Backlog Items, …  Customized dashboards, report and chart generating  Extensible platforms with 100+ available plugins:  Sonar for Jira  TFS4JIRA  …  Works great with other Atlassian products: Confluence, Bamboo, BitBucket, FishEye, Crucible  Issues can be made public for feedback and bug reporting

28. OTHER ATLASSIAN PRODUCTS  BitBucket  Source Code Repository (uses Mercurial or Git)  Includes Add-ons for deployment (AWS CodeDeploy, Azure)  Inline comments, Pull Requests, Branches, …  Bamboo  Continuous Integration and Deployment  Provides build tools for most languages  Deployment to AWS, Azure Service and Docker support  Confluence  Wiki tool for work organization, document creation and discussions  File Collaboration  Loosely compared to Microsoft SharePoint

29. JIRA FISHEYE AND CRUCIBLE  Code Review tool  Provides in-line discussions and threaded conversations  User role separation  Integrated with FishEye  Code Snippet Reviews  On-Premise repository browsing tools  Powerful indexing, searching, Diff views  Different types of repositories (Git, Perforce, …)  Source code is read only  Activity streams from commits, Jira issues and Crucible review items

30. DEMO: FISHEYE AND CRUCIBLE

31. Thank You Questions