Agiletools

232 views

Published on

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
232
On SlideShare
0
From Embeds
0
Number of Embeds
27
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • About NG product: it is a web based Java/ J2EE application for loan processing
  • We also have unit tests implemented with coverage > 60% hence we have followed all of the agile processes
  • Software has to go through various filters before it is deemed usable, when do these happen for you? Right now we have a hardening sprint and sometimes a SWAT sprint where everyone gears up to find bugs and then fix them. These steps use tools and time of dedicated experts who are shared across teams. Having someone dedicated to a sprint team is not possible. So the point I want to make here is that even though deemed fit by a Scrum team a product has to go through other phases before it is actually usable. Going through all of these phases in 15 day sprint is not possible without the use of tools
  • There is no clear benefit to the company and customer? Our sprint releases are not shipped to our customers, factoring in the fact that we do not have any external customers. Unless we have a customer other than the product owner who sees the development per sprint or per two sprints they will not see the advantage of using agile to speed up software development
  • It appears even though we are following all agile practices we are violating the very foundation on which it stands. The benefits of adopting these practices should be seen by the team, organization and customer. Where the order should be customer first whereas the customer does not see a big advantage in the current scenario. The problem is that whole implementing Agile the teams tend to think of it as a tool to improve engineering discipline whereas they tend to forget the customer angle which is of paramount importance.
  • Software development in general is a risky business. We depend on humans to write code and humans have emotions which makes them different from machines. The above presents another angle to the software development business which are the associated risks this may not be the wholesome picture and there may be more than these which will vary across companies and teams but these are some which are common across teams I have worked with.
  • Finally we have to give a hearing to the team people who are making sure that the cogs turn and an output is produced. They are already pushed against a wall as they have to take up very short tasks which are of measurable business output. Measurement of velocity ensures constant improvements, the developers are already writing units to ensure coverage adding the testing burden to a team member is not something they are ready for.
  • Agiletools

    1. 1. No tools == No Agile!
    2. 2. Agenda Introduction Scrum @Nucleus Scrum @Nucleus with tools Screenshots Traceability Achievements & Vision Potential pitfallsQ&A
    3. 3. Introduction 3
    4. 4. My involvement with software products started in 2000 and has continued till date. I have been an Agile practitioner for ~5 years and have played multiple roles of developer, scrum master, architect and product manager. I have worked with products in all stages of the product lifecycle right from inception to maintenance and EOL.Currently @Nucleus working with ~4 Scrum teams following Lean and Agile principles to create the next generation product.
    5. 5. Scrum @Nucleus 5
    6. 6. Scrum •Daily Scrum •Daily Work •Daily Cycle •Sprint planning meeting PREPARATION •Business case & funding •Contractual agreement •Vision •Initial productbacklog RELEASE •Initial release plan SCRUM PROCESS •Product •Stakeholderbuy-in increment •Update •Assemble team product backlog •Impediment List •Scrum master •Product backlog •Sprint •Sprint retrospective review•Product backlog Delta •Product ownerreport SCRUM SCRUM ROLES ARTEFACTS •Product backlog burndown •Users •Stakeholders •Sprint backlog •Sprint backlog burn down
    7. 7. My team @Nucleus Follow the book We have a flat team structure We publish a sprint, version and release dashboard The teams are in the range of 8 We retrospect on the glad/ to 10 people mad/ sad points in a sprint and The team was trained assign actions from them effectively on Scrum & Agile Scrum master is not doing any project management Scrum masters are mentoring the team membersTeam members are coached totake ownership of the work done We create all backlogs: release, version, sprint & impediment We perform all of the Scrum ceremoniesSprints are demoed to PO andrecorded
    8. 8. Done? When team says they are “DONE” for a * release Quality Control Functional testing – running the entire suite of tests Penetration testing done by a team ofPenetration Testing internal expertsPerformance Testing Perforance testing done using performance test automation tools System testing / internal UAT done by System testing senior business analysts/ domain experts Integration testing done with other core Integration testing banking/ external systems
    9. 9. So… Question 1:Not putting a number/ percentage on compliance but doyou think we are following Agile? Question 2:Does Nucleus as a company see benefits/ gains from thischange in software development methodology? Question 3:Do our customers appreciate this change methodology, isthere any value they derive from this?
    10. 10. But…“Our highest priority is to satisfy the customer through early and continuous delivery of valuable software. “ From the agile Manifesto
    11. 11. RisksFixing bugs late is costly: Cost:Finding and fixing bugs late is Associated cost of doing thesecontradictory to fail early principle things manually and as a large chunk versus doing them slowly as part of each sprintQuality of code:What is the code quality, potentialdefects/ performance issuesinduced by bad quality of code.Critical path failures:How many times does a checkinlead to a completely dysfunctionalproductNon-deployable software:Against Agile philosophy of havingdeployable software after everyreleaseCode merge:When working with distributedteams code merges which aredelayed may create complexissues low risk medium risk high risk
    12. 12. Developers when asked to test How do you expect us We can get a QC person to estimate, code and on the team later and test in the same 2 then have a couple ofOops did you week cycle? hardening cycles totalk about SOPs I ensure quality is takenuse them for Cant we just rely on care ofdebugging the product owner, it is his job to mark it as done? I am a developer not a Why do we need to tester! run performance tests now, I mean there is still 6 months left to deliver? Use It is humanly impossible tools to do everything in a short timebox, with <=10 people without using proper tools.
    13. 13. Scrum @Nucleus With Tools 13
    14. 14. Scrum @NucleusProcess & Metrics SuccessfulAgile Tools DeliveriesAgile Teams
    15. 15. Continuous IntegrationContinuous integration is a development philosophy of “on checkin” developer integrations verified by automated builds and deployments. 1 Compilation Junit Java docs execution DB Performance integration & tests migration Functional Code tests inspection Deployment
    16. 16. Setup Prepare Product Backlog JIRA Target Deployment Server SVN Repository Update JIRAProduct Owner Check out sources Eclipse STS Mylyin Plugin Deploy Share Results JIRA Task Board Run Tests Close Task Open Task Logs Time Notifies Jenkins to trigger build Sonar Build Email Maven Feedback Developers SubEclipse Plugin Continuous Integration Server Jenkins
    17. 17. Tools used Eclipse Sonar IDE with plug- Code Quality Jenkins / Fish Eye ins and Coverage Maven Per checkin Traceability Builds J – Units/ SVN Selenium Source Code Automated Library Test SuiteJIRA Nexus Agile based Internal Project Automation maven Management repository Sprint is of 2 weeks. In which all engineering activities need to take place 17
    18. 18. Screenshots 18
    19. 19. Checkin Email
    20. 20. JIRA Traceability Traceability: Mapping to JIRA
    21. 21. Dev Build
    22. 22. Unstable Build
    23. 23. Junit Test Report
    24. 24. Build Summary
    25. 25. Integrated functional & performance tests Functional tests Performance tests
    26. 26. Code Quality
    27. 27. SCM Statistics
    28. 28. Traceability 28
    29. 29. Traceability Quality AuditProduct Owner Scrum Team Quality Control Team Product metrics, User stories Product health score Dev tasks, Test scenarios, test enhancements, Traceability via JenkinsTraceability in cases, test case and JIRA defects and changeJIRA execution requests Traceability to dev tasks in JIRA via common user stories 29
    30. 30. Achievements & Vision 30
    31. 31. Achievements• Reduced count of build failures• Increased overall test coverage• Improved traceability and ability to find root cause for defects• Team focus on delivering product• Reduced cost incurred on build & release management• The team sees value of build & release and is focused on “continuous improvements”• Team feels more confident of the delivery made to the customers
    32. 32. Vision Repeat the model for multiple product Manage teams and customer improve further deployments for by cutting down patch releases/ on waste core upgradesIntegrate onlinefunctionalperformance andpenetrationscripts as part ofbuild
    33. 33. Potential pitfalls 33
    34. 34. Human Factor Do not forget we are dealing with 1 human beings and they have limitationsWhat is a build? The greatest factor for any Agile implimentation is the fact that we are dealing with human beings What is a build, the definition needs 2 to be clear and we need to perfect the team not the process. A lot of times we get carried away with theLocus process forgetting that process is meant to improve the team and the end goal is to improve The key player is the build engine: the team 3 JenkinsIncremental process Treat build & release as an 4 incremental process and better it in every sprint
    35. 35. Human Factor Do not forget we are dealing with 1 human beings and they have limitations Build may have different meanings for differentWhat is a build? people while some may think that it is successful compilation others may go beyond. What is a build, the definition needs 2 to be clear It is very important to emphasize and make everyone agree on one common build definition then live with it.Locus The starting point for feature/ debt addition is at The key player is the build engine: the developer desk we have to make sure what is 3 Jenkins being checked in is sanitized.Incremental process Treat build & release as an 4 incremental process and better it in every sprint
    36. 36. Human Factor Do not forget we are dealing with 1 human beings and they have limitations It is very important that teams have this skillWhat is a build? without which either we will have a superfluous setup or a setup which does not work. What is a build, the definition needs 2 to be clear It is the build engine which orchestrates the entire flow after each checkin we need to understand and plan very meticulously for example:Locus • What will happen if someone checks in The key player is the build engine: code when build is broken? 3 Jenkins • What will happen if a build is in progress and someone checks in code? • The right notification schemeIncremental process • The right dashboards Treat build & release as an 4 incremental process and better it in every sprint
    37. 37. Human Factor Do not forget we are dealing with 1 human beings and they have limitationsWhat is a build? What is a build, the definition needs While it may be nice to have everything up in one 2 to be clear go, we need to factor in product specific parameters. The goal is to reach a mutually accptable build and release configuration whichLocus meets the product, team and business considerations. One solution may not fit all needs The key player is the build engine: and even exisiting solutions may need constant 3 Jenkins updation to get to the right configuration.Incremental process Treat build & release as an 4 incremental process and better it in every sprint
    38. 38. Questions? 38
    39. 39. Thank You 39

    ×