The Live Source Agile Experiment

1,206 views

Published on

Source Agile is an Agile Toolkit

A new technology for your software, clarifying the darkness of programming into an easy to read, step by step summary of the content. Just program well and let Live Source Agile do the rest.

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,206
On SlideShare
0
From Embeds
0
Number of Embeds
17
Actions
Shares
0
Downloads
5
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • Main problem in software is miscommunication
  • Maintainability – classes and packages are named/grouped in a way that makes sense in the real world
    Agility improve -
    Precise Communication
  • The common language is in the middle and not more of business language nor technical language
    Somewhere in between, not programmers completely conforming to biz language
  • 2454 lines of code
    XX Methods
  • c
  • New communication channel
    This
  • Edit class comments
    Helps managers to communicate with programmers
    Contextualize the conversation with the real code
    Helps
  • Exposes the project classes
    If you write in Ubiquitous Language your code should be easy to read.
    Makes the managers familiarizes with what programmers are doing
  • Exposes the project classes
    If you write in Ubiquitous Language your code should be easy to read.
    Makes the managers familiarizes with what programmers are doing
  • Exposes the project classes
    If you write in Ubiquitous Language your code should be easy to read.
    Makes the managers familiarizes with what programmers are doing
  • We understand each other
    Software development is by its nature a series of translations and compromises. What the end user wants, what the customer is willing to pay for, and what is technically feasible rarely combine to form a unified set of features. In this talk we will explore how an Agile team can work to understand each other better, in particular at the communication divide between stakeholders and developers. We will show you how to develop a domain-specific ubiquitous language, how to lessen the responsibility gap between managers and developers, and how to use your codebase as the central source for documentation.
  • The Live Source Agile Experiment

    1. 1. The Live Source Code Experiment an AGILE TOOLKIT Plus an experimental tool that shows live code some respect! Alline Watkins & June Clarke
    2. 2. Getting the most of your source code Does your source code lack knowledge? Is it a multiple lined mess that just doesn't make any sense to anyone, even possible you? If you or one of your employees left work now, would others be able to make sense of it? Source Agile is a new technology for your software, clarifying the darkness of programming into an easy to read, step by step summary of the content. Just program well and let Source Agile do the rest.
    3. 3. The Hypotheses Source Code as Live Documentation Source Code as Communication Channel Source Code as Planning Tool Source Code as Software Metrics ? ? ? ? ?
    4. 4. The advantages... Faster communication Less risk of miscommunication (bugs & bad features) Knowledge of domain resides in codebase Overhearing (sit together) Code is easier to understand (maintainable, extensible) Healthier code allows team to respond to change
    5. 5. UBIQUITOUS LANGUAGE & DECOUPLING VERY IMPORTANT:
    6. 6. u·biq·ui·tous /yoo bikwətəs/ˈ͞ Adjective: Present, appearing, or found everywhere. Synonyms: omnipresent (Dictionary.com) UBIQUITOUS LANGUAGE . A language structured around the domain model and used by all team members to connect all the activities of the team with the software. (Excerpted from Domain-Driven Design by Eric Evans) . We understand each other. (Excerpted from The Art of Agile Development by James Shore and Shane Warden, published by O'Reilly. Copyright © 2008 the authors. All rights reserved.)
    7. 7. NO When User logs on with valid credentials, an empty panel is displayed. (from a Tic Tac Toe software example) User Story Example: YES When Player logs on with valid credentials, an empty board game is displayed. (from a Tic Tac Toe game software example)
    8. 8. NO . Integer i = new Integer(); . String char1 = new String(); . public class GameDAO() { } . catch (Exception e) Coding Examples: YES . String realMeaningOfMyString = new String(); . public class ScoreDataLoader() { } . catch (Exception NotLoggedInException) NO . Ambiguities . Inconsistencies . Synonyms . Abbreviations YES . Clarity . Precision . Reuse . Full Names
    9. 9. Tree term2Rest(Tree t, int minprec) { List<Tree[]> savedOd = odStackSupply.elems; Tree[] odStack = newOdStack(); List<Tokens[]> savedOp = opStackSupply.elems; Tokens[] opStack = newOpStack(); // optimization, was odStack = new Tree[...]; opStack = new Tree[...]; int top = 0; odStack[0] = t; int startPos = S.pos(); Tokens topOp = ERROR; while (prec(S.token()) >= minprec) { opStack[top] = topOp; top++; topOp = S.token(); int pos = S.pos(); S.nextToken(); odStack[top] = topOp == INSTANCEOF ? type() : term3(); while (top > 0 && prec(topOp) >= prec(S.token())) { odStack[top-1] = makeOp(pos, topOp, odStack[top-1], odStack[top]); top--; topOp = opStack[top]; } } assert top == 0; t = odStack[0]; if (t.tag == Tree.PLUS) { StringBuffer buf = foldStrings(t); if (buf != null) { t = F.at(startPos).Literal(TypeTags.CLASS, buf.toString()); } } odStackSupply.elems = savedOd; // optimization opStackSupply.elems = savedOp; // optimization return t; } Class com.sun.tools.javac.parser.Parser; REAL WORLD EXAMPLE # Lines of Code = 2.454
    10. 10. Where this fits with Agile Agile manifesto: Working software over comprehensive documentation Values: transparency & unity XP Practices: feedback, pairing,
    11. 11. One step further... Create a medium that allows both stakeholders and programmers to work on code in a high-level manner. Integrate user stories and tasking more tightly with codebase. Let code rule!
    12. 12. The Live Source Code an Agile Experiment The Toolkit:
    13. 13. http://sourceagile.appspot.com
    14. 14. Loading your source code inside the Toolkit
    15. 15. Showing the source code in an easy-to-read way
    16. 16. Offering a Communication Channel
    17. 17. Unit Testing connections and helps
    18. 18. Planning Tool
    19. 19. Automatically generated Live Documentation
    20. 20. Software Metrics
    21. 21. What you get: - keeps the intention of the project in mind - higher quality work (published code is likely to be better) - managers understand the repercussions of what they are asking for - live documentation that is closer to a user manual than javadocs - easier for programmers to argue for time to refactor, [.....] .
    22. 22. alline.oliveira@gmail.com joonspoon@joonspoon.com http://www.slideshare.net/allineoliveira/source-agileexperiment

    ×