CSC/ECE 517 Fall 2012/ch2a 2w7 ma: Difference between revisions

From Expertiza_Wiki
Jump to navigation Jump to search
No edit summary
 
(131 intermediate revisions by 2 users not shown)
Line 1: Line 1:
<p>Code Reuse - This page describes what is code reuse, how to achieve it and discusses the advantages and disadvantages of code reuse.</p>
<p>Scrum Tools - This page gives survey of the tools that can be used for practicing scrum. It considers the features offered by each of them, the scenarios in which each of them can be used considering what features it has and what features it lacks, cost involved etc.</p>


== Definition ==
== Overview <ref name = "Scrum" />==
Code reuse is the way in which an existing code can be used to perform a specific service regardless of the application in which it is used.<ref name = wiki_code_reuse/> It involves the use of some previously constructed [http://en.wikipedia.org/wiki/Software software] artifacts like source code, library, components, etc. An example of it can be the design patterns in a new context or in a new development project.


Software reuse is the process of creating software systems from existing software rather than building software systems from scratch.<ref name = "definition_software_reuse" />
===Scrum===
[http://en.wikipedia.org/wiki/Scrum_(development) Scrum] is an [http://en.wikipedia.org/wiki/Iterative_and_incremental_development iterative and incremental agile software development]<ref name = "iterative" /> method for managing software projects and products or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of [http://en.wikipedia.org/wiki/Empirical_process_(process_control_model) empirical process control], where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management. It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.


== Overview <ref name = wiki_code_reuse/>==
===Scrum Tools===
Code reuse is the idea that a partial computer program written at one time can be, should be, or is being used in another program written at a later time. The reuse of programming code is a common technique which attempts to save time and energy by reducing redundant work.
Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the [http://www.daily-scrum.com/scrum/sprint/backlog sprint backlog]. There are also [http://en.wikipedia.org/wiki/Open_source open-source] and [http://en.wikipedia.org/wiki/Proprietary proprietary] packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their [http://en.wikipedia.org/wiki/Artifact artifacts] in hard-copy forms such as paper, whiteboards and sticky notes.


The software library is a good example of code reuse.
== Selecting The Right Tool <ref name = Selecting_the_tool/>==


Programmers may decide to create internal [http://en.wikipedia.org/wiki/Abstraction_%28computer_science%29 abstractions] so that certain parts of their program can be reused, or may create custom libraries for their own use.
Here are some of the factors which should be considered before selecting the correct scrum tool -


The general practice of using a prior version of an extant program as a starting point for the next version, is also a form of code reuse.
=== Primary Factors ===


Some so-called code "reuse" involves simply copying some or all of the code from an existing program into a new one. While organizations can realize time to market benefits for a new product with this approach, they can subsequently be saddled with many of the same code duplication problems caused by [http://en.wikipedia.org/wiki/Cut_and_paste_programming cut and paste programming].
* Does the tool improve visibility?
- Scrum requires transparency to succeed. Everyone who needs to know about the project from the developers to the [http://en.wikipedia.org/wiki/Stakeholder stakeholders] and maybe even the customer should be able to use the tool. There is no point using a tool if only a [http://www.mountaingoatsoftware.com/scrum/scrummaster Scrum Master] or a few people can use it and everyone else has to rely on email.


Many researchers have worked to make reuse faster, easier, more systematic, and an integral part of the normal process of programming. These are some of the main goals behind the invention of [http://en.wikipedia.org/wiki/Object-oriented_programming object-oriented programming], which became one of the most common forms of formalized reuse.
* Does the tool improve communication?
- Tools can be used to open up channels of communication. For example, allowing a developer to comment on a [http://en.wikipedia.org/wiki/User_story user story] and have a remote customer reply back – setting up direct communication between developer and customer and bypassing all the bureaucracy in the middle.


A somewhat later invention is [http://en.wikipedia.org/wiki/Generic_programming generic programming].
* Does the tool reinforce trust?
- Example: A team member forgot to update the estimate for Friday. He remembers on Monday. Can you set the estimate for Friday on Monday? In a “high trust” tool like pen & paper: you can just pick up a pen and redraw the [http://msdn.microsoft.com/en-us/library/ff731588.aspx burndown]. In a “low trust” tool, you cannot do this because it is considered as meddling with the past recorded history of actions.


Another, newer means is to use software "[http://en.wikipedia.org/wiki/Source_code_generation generators]", programs which can create new programs of a certain type, based on a set of parameters that users choose. Fields of study about such systems are [http://en.wikipedia.org/wiki/Generative_programming generative programming] and [http://en.wikipedia.org/wiki/Meta_programming meta programming].
* Does the tool adapt to the way you work?
- Each team is going to use the tool differently. Some tools adapt to the way you work, other tools force you to work the way the tool is setup. Because of the self-managed nature of scrum, it is important that the tool support the team, and the team should not have to change their working to fit the tool.


== History ==
=== Secondary Factors ===
[http://en.wikipedia.org/wiki/Ad_hoc Ad hoc] code reuse has been practiced from the earliest days of programming. Programmers have always reused sections of code, templates, functions, and [http://en.wikipedia.org/wiki/Procedure_%28computer_science%29 procedures]. Software reuse as a recognized area of study in software engineering, however, dates only from 1968 when [http://en.wikipedia.org/wiki/Douglas_McIlroy Douglas McIlroy] of [http://en.wikipedia.org/wiki/Bell_Labs Bell Laboratories] proposed basing the software industry on reusable components. <ref name = wiki_code_reuse/>


There are many dimensions along which we can trace the history of reuse: <ref name = history_pros_cons/>
* Standalone, monolithic or integrated :
* [http://en.wikipedia.org/wiki/Software_Development_Life_Cycle Software Development Life Cycle] (SDLC) Model
* [http://en.wikipedia.org/wiki/Prototyping Prototyping], Iterative, ESP, etc.
* Requirements/Specification Method
* Business Model
* Implementation technology
=== History of software reuse based on implementation technology dimension <ref name = history_pros_cons/>===
* Mid 1980’s - Mature Third Generation Programming Languages -
Third generation languages were more portable than the earlier machine specific languages; even though source code still had to be language, [http://en.wikipedia.org/wiki/Operating_system OS] and platform specific. However they did achieve limited source code reuse for high value. e.g. math libraries.


* Late 1980’s - Early Object Oriented Languages and SQL DB -
- Standalone tools let you create users, stories, iterations and tasks and generate some reports like [http://msdn.microsoft.com/en-us/library/ff731588.aspx burndown] or velocity. Basic, but useful when you want something simple.
Introduction of object oriented languages like [http://en.wikipedia.org/wiki/Common_Lisp_Object_System Common Lisp Object System (CLOS)], C++ interpreter, etc provided encapsulation and packaging technology.Packaging and common object models promoted development of language “bindings”. Systematic and repeatable object oriented development processes were also introduced during this time. Although most [http://en.wikipedia.org/wiki/Portability_%28computer_science%29 portability] constraints remained as they were, some reuse success was achieved in the form of high value data structure libraries (e.g. GRACE and Booch parts). The first successful reusable service of SQL [http://en.wikipedia.org/wiki/Relational_database_management_system RDBMS] was developed during this period.


* Early 1990’s - Mature OO Languages, Source Code Libraries -
- Integrated tools do only project management, but they can integrate with external tools like other bug tracking tools, source control, wikis and so on. For example, you will be able to synchronize bugs from the bug tracker to the PM tool or link tasks in the tool with code commits and so on. They can provide an overview across multiple tools in use.
This era saw development of mature OO languages like [http://en.wikipedia.org/wiki/Smalltalk Smalltalk], ANSI [http://en.wikipedia.org/wiki/CLOS CLOS], C++ compilers, [http://en.wikipedia.org/wiki/GUI GUI] and [http://en.wikipedia.org/wiki/Event_driven_programming Event Driven Programming] Libraries and portable compiled software packages like Shared Libraries, Dynamic Link Libraries, etc. Significant reuse research was carried out during this period(e.g. SPC CoE for Reuse/ARPA contract) which gave birth to early software reuse driven processes and reuse libraries (like management systems, not just content)


* Mid 1990’s - Early DIAE Component Packaging -  
- Monolithic tools support the entire life-cycle like document management, bug tracking, artifact management over and above standard PM functionality all within a single tool. Advantages of monolithic are that all components are tightly integrated. Disadvantage is that you have to discard all your existing tools to move to a monolithic one. Also if the monolithic tool does not support a particular component (like continuous integration or code analysis) you may still have to use multiple tools.
Dynamically Integrable Autonomously Executable Components that are compiled and linked separately, integrate at run time, and run independent of each other were developed during this period. (e.g. COM and CORBA). Distributed systems which formed the foundation for [http://en.wikipedia.org/wiki/Web_services Web Services] and [http://en.wikipedia.org/wiki/Component-based_development Component Based development processes] were introduced.
Advances like these also gave rise to commercially successful code generators like Netron, Frame Technology and reusable component vendors like [http://en.wikipedia.org/wiki/Infragistics Infragistics].


* Late 1990’s - Mature DIAE Components, Cross-Protocol Bridges -
* Usability :
Along with introduction of Cross Protocol Bridges which allow [http://en.wikipedia.org/wiki/COM_%28hardware_interface%29 COM] and [http://en.wikipedia.org/wiki/Cobra_%28programming_language%29 CORBA] systems to participate in the same system, Light weight integration protocols like [http://en.wikipedia.org/wiki/SOAP SOAP] were introduced in this period. New reusable component packaging mechanisms were invented. Reuse based development processes matured with time and specialized reusable component market got established.


* 2000-2005 - Early [http://en.wikipedia.org/wiki/Service_Oriented_Architecture Service Oriented Architecture] Products -
- How usable is the tool? When you have poor usability, people may resent working with the tool and might start working around the tool instead. Tools with poor usability may also call for additional unplanned expenditure in training and support. You also have issues of general resentment by the team at whoever foisted the tool upon them.
This era saw rise of Service Oriented Architecture and rediscovery of reuse research like Software Reuse (Asset) Management Systems, Domain Specific Reuse, Domain Languages (Software Factories), etc.
It was understood that reuse must reuse more than just code and it would require drastic process changes. [http://en.wikipedia.org/wiki/Design_pattern_%28computer_science%29 Design patterns] were also created during this time.
Reuse Successes during time include - Microsoft .Net Framework, SRMS: Flashline and LogicLibrary.


== Techniques <ref name = techniques/>==
* Pricing model :
In re-using code, we have several levels of granularity


=== Single lines of code ===
- Is the tool open source, free or commercial? For commercial tools, it the pricing per-user or per-project? Subscription or one-time payment? What is your risk exposure should the team size or number of projects increase? What is the total cost of ownership, including training, support, customizations etc. How does it fit your budget?
For example, in [http://en.wikipedia.org/wiki/Ruby_%28programming_language%29 Ruby] to print an array containing 5 elements we simply use the following
<pre>
[ 'Sam', 'John', 'Gita' ].each {|name| print name, " " }
</pre>
outputs :
Sam John Gita.


=== Procedures, Macros ===
==Low Tech Scrum Tools<ref name = simple_scrum_tools/>==
Procedures and macros are the low level code reuse techniques
*Index cards :
A macro is a group of repetitive instructions in a program which are codified only once and can be used as many times
- The [http://en.wikipedia.org/wiki/Extreme_programming eXtreme Programming (XP)] community swears by the use of standard index cards for a wide variety of modeling techniques, and in particular [http://en.wikipedia.org/wiki/Class-responsibility-collaboration_card Class Responsibility Collaborator (CRC]) modeling.  
as necessary.  
<pre>
Position MACRO Row, Column
PUSH AX
PUSH BX
PUSH DX
MOV AH, 02H
MOV DH, Row
MOV DL, Column
MOV BH, 0
INT 10H
POP DX
POP BX
POP AX
ENDM
</pre>
A procedure is a collection of instructions to which we can direct the flow of our program, and once the execution of these instructions is over control is given back to the next line to process of the code which called on the procedure.
<pre>


Adding Proc Near ; Declaration of the procedure
*Post-It notes :
Mov Bx, 0 ; Content of the procedure
- Post-It notes are also an option, for example one can develop an abstract/essential [http://en.wikipedia.org/wiki/User_interface user interface] prototype using Post-Its on large sheets of paper.  This is part of a technique called essential user interface modeling. 
Mov B1, Ah
Mov Ah, 00
Add Bx, Ax
Ret ; Return directive
Add Endp ; End of procedure declaration


</pre>
*Paper :
- Pieces of paper, or index cards, tacked onto a whiteboard and connected by strings can be used for a wide variety of models.  For example the individual sheets of paper can represent database tables and the lines relationships between tables on a physical data model, or the sheets can represent screens and the strings navigation flows between screens on a user interface flow diagram, or the sheets can represent use cases and actors and the strings represent associations between them on a [http://www.andrew.cmu.edu/course/90-754/umlucdfaq.html UML use case diagram].


=== Functions/methods ===
*Plain old whiteboards (POWs) :
For example, in Ruby a method can be written as follows
- A whiteboard for sketching on is likely the most common modeling tool in use.  A digital camera can easily make copies of sketches that one wants to keep.
<pre>
def convert_to_farenhite(temperature_in_celcius)
result = temperature_in_celcius * (9/5) +32
return result
end
</pre>


=== Components ===
==Examples of Open Source Scrum Tools<ref name = "Examples_of_open_source_scrum_tools" />==
When you are building software, objects are created in code, and reusable objects that perform specific services in different circumstances are called components.
Here are some of the examples of open-source scrum project management tools -
When you use Microsoft® Office to build custom applications, you write code that leverages the power of Office components. Using an Office component means you are not only excused from writing the code yourself, but you are using a component that has been tested and found reliable in different conditions.


=== Object orientation <ref name = Object_orinetation />===
===Agilefant<ref name = agilefant/>===
High level languages also come with effective abstractions to build and share "abstract data types" and other "reusable libraries". Source code components are generally intended to be used as black-boxes: a public interface of usage is announced, formally or not (ruby has not equivalent of java interfaces, for example), while the realization of this interface is kept hidden (or at least intended to be). Think to C libraries, java's .jars, python's modules, ruby's gems, and so on. In many languages, "find a component, download it, and go" has become a reality!
[[File:AgileFant.png|thumb|Agilefant's Development Porfolio|upright=1.25]]


==== Packages ====  
=====Overview=====
A Java package is a mechanism for organizing Java classes into namespaces similar to the modules of Modula. Java packages can be stored in compressed files called [http://en.wikipedia.org/wiki/JAR_%28file_format%29 JAR] files, allowing classes to download faster as a group rather than one at a time. Programmers also typically use packages to organize classes belonging to the same category or providing similar functionality.
Products are the highest level construct, and each deployment may have multiple products. Each product may have one or more projects, which are essentially releases. Each project may have one or more iterations. Each product, project (think "release"), and iteration has its own backlog, which contains stories. Stories can be moved to any other backlog, for example from the product backlog to an iteration backlog. Stories may consist of zero or more tasks. Projects can be prioritized in the Portfolio view.
A package provides a unique namespace for the types it contains.
Classes in the same package can access each other's package-access members.


==== Modules ====
The tool supports multiple concurrent iterations, which allows larger organizations to use the tool effectively.
Modules are a way of grouping together methods, classes, and constants. An example of a Ruby module is as follows
<pre>
module Trig
PI = 3.141592654
def Trig.sin(x)
# ..
end
def Trig.cos(x)
# ..
end
</pre>


====[http://en.wikipedia.org/wiki/Inheritance_%28computer_science%29 Inheritance] ====
Agilefant supports multiple users and users can be grouped into teams. However, it does not support any user roles; a user is a user, with no differences in permissions or access to features. Teams can be assigned to specific iterations.
In object-oriented programming (OOP), inheritance is a way to reuse code of existing objects, or to establish a subtype from an existing object, or both, depending upon programming language support. In classical inheritance where objects are defined by classes, classes can inherit attributes and behavior from pre-existing classes called base classes, [http://en.wikipedia.org/wiki/Superclass_%28computer_science%29#Subclasses_and_superclasses superclasses], parent classes or ancestor classes. The resulting classes are known as derived classes, subclasses or child classes. The relationships of classes through inheritance gives rise to a hierarchy. The basic mechanism of subclassing is simple. The child inherits all of the capabilities of its parent class — all the parent’s instance methods are available in instances of the child. Let’s look at a trivial example and then later build on it.  


Here’s a definition of a parent class: <pre>
Version 1.6.2 does not include the concept of higher-level features or epics, although this feature is promised in version 2.0 which is supposed to be released soon. It does support the concept of themes, which are an attribute of stories, and this does provide a simplistic way to associate a group of stories.
class Parent
def say_hello
puts "Hello from #{self}"
end
end


p = Parent.new
=====Strengths=====
p.say_hello


</pre>
*Rich feature set.
Output:
*Usability - Agilefant is intuitive.It lacks “[http://en.wikipedia.org/wiki/Drag_and_drop drag and drop]” features, but it otherwise makes good use of client-side features that make the user interface more responsive.
Hello from #<Parent:0x0a40c4>
*Suitable for larger organizations and projects, except for the lack of “epics” or story hierarchies. (Version 2.0 should fix that shortcoming.)
*Reasonably intuitive and easy to use.
*Portfolio planning feature.
*Timesheet feature.


and a child class that inherits from it:
=====Weaknesses=====
<pre>
# Subclass the parent...
class Child < Parent
end
c = Child.new
c.say_hello


</pre>
*Stories can be estimated in hours only, not points.
*Stories cannot be ranked absolutely; they can only be prioritized on a scale of 1 to 5.
*No “drag and drop” re-ordering of stories.
*No “epics” or hierarchy of stories. Note that a story hierarchy is promised for version 2.0.
*No “task board” or “whiteboard” view.
*No differentiation between user roles.


Output:
===IceScrum<ref name = icescrum/>===
Hello from #<Child:0x0a3d68>
[[File:product_backlog_view.jpg|thumb|IceScrum's Product Backlog view|upright=1.25]]


The parent class defines a single instance method, say_hello. We call it by creating a new
=====Overview=====
instance of the class and store a reference to that instance in the variable p.
Products (also called projects in some places) are the highest level construct, and each deployment may have multiple products. Each product has a single [http://en.wikipedia.org/wiki/Scrum_%28development%29#Product_Backlog backlog] and a roadmap. A backlog contains features (similar to epics), [http://en.wikipedia.org/wiki/User_story user stories], defects and technical stories. A roadmap contains multiple releases, each of which has a single release plan. A release plan consists of multiple [http://en.wikipedia.org/wiki/Sprint_%28scrum%29#Sprint sprints]. Each sprint contains stories, which in turn contain tasks and acceptance tests. Impediments can be tracked for each product.
We then create a subclass using class Child < Parent. The < notation means we’re creating a
subclass of the thing on the right; the fact that we use less-than presumably signals that the
child class is supposed to be a specialization of the parent.
Note that the child class defines no methods, but when we create an instance of it, we can
call say_hello. That’s because the child inherits all the methods of its parent. Note also that
when we output the value of self — the current object - it shows that we’re in an instance of
class Child, even though the method we’re running is defined in the parent.


===Generators<ref name = generators/>===
Unlike Agilefant, IceScrum includes a task board/whiteboard view of the iteration, allowing tasks to be dragged and dropped. It also allows drag and drop ranking of [http://en.wikipedia.org/wiki/User_story user stories] in the backlog. Many options are available only from a right-click context menu, which isn’t obvious at first but is easy to use once you notice it.
Source code generation is the act of generating source code based on an [http://en.wikipedia.org/wiki/Ontology_%28information_science%29 ontological] model such as a template and is accomplished with a programming tool such as a template processor or an [http://en.wikipedia.org/wiki/Integrated_development_environment IDE]. These tools allow the generation of source code through any of various means. A macro processor, such as the C preprocessor, which replaces patterns in source code according to relatively simple rules, is a simple form of source code generator. [http://en.wikipedia.org/wiki/Parser Parser] generators (lex & yacc, antlr, rats!, treetop, pyPEG, and so on.) are probably the best-known examples of application generators. Other examples include [http://en.wikipedia.org/wiki/Wizard_%28software%29 wizards] that one can find in Integrated Development Environments (to design and generate code of user interfaces, for example), tools that generate classes from UML class diagrams, generators of database schemas, report generators, etc.


===Software architectures===
IceScrum is the only product reviewed that has a planning poker feature. This feature allows a distributed team to play planning poker for estimating features and [http://en.wikipedia.org/wiki/User_story user stories].
Software architectures are large-grain software frameworks. In contrast with source code components which are often black-boxes, software architecture are designed as grey-boxes: they are intended to be extended and provide specific extension points for this. We have a lot of reusable frameworks nowadays. Probably the most common are web frameworks (Ruby on Rails, django, ASP.net, ...), integrated development environment (IDE, Eclipse is worth mentioning due to its architecture), service oriented architectures (SOA), and so on.


===Design and code scavenging===
IceScrum allows only a single release and single sprint to be active at one time (for a particular product), making it unsuitable for larger organizations that need multiple concurrent sprints with multiple teams running in parallel for a single product.
Design and code scavenging is simply a form of "find, copy-paste, adapt". The well-known [http://en.wikipedia.org/wiki/Software_design_pattern design patterns] provide an organized form of design scavenging, by providing catalogs for applying such kind of reuse. Even if invented in the context of the object-oriented programming, design patterns had a great impact far beyond that programming [http://en.wikipedia.org/wiki/Paradigm paradigm].


Code scavenging is less organized as few such catalogs exists. Every day however, the web gives users better ways to apply reuse techniques such as google code search, github's gist, pastie, and so on.
IceScrum users may have any of the Scrum roles (Product Owner, Scrum Master, Team Member, Stakeholder) plus custom roles may be created. It does not allow users to be grouped into teams.


===Transformational systems===
Beyond a burndown chart, IceScrum does not have any reports or reporting API.
Transformational systems are the holy grail of computer science, nothing less! In that paradigm, software developers actually describe the behavior of the software using a high-level specification language (related to VHLL described before). In a second phase, the specifications are transformed in order to produce an executable system. The transformations are meant to enhance efficiency without changing the semantics.


Transformational systems emphasizes the what instead of the how. They actually bet on the concision of declarative statements over procedural ones to achieve effective reuse. While general purpose transformation systems remain mostly research topics, notable results have been achieved in some specific domains: relational systems come with effective query optimizers, some rapid prototyping approaches using transformations from high-level descriptions down to code, etc.
=====Strengths=====
*Rich feature set.
*The Sprint Backlog view resembles a physical task board quite effectively.
*The Roadmap, Release Plan and Sprint Plan views support multiple levels of planning.
*Acceptance tests can be recorded for each story. A BDD-inspired template for acceptance tests is available.
*Includes a planning poker feature.
*Supports absolute ranking of stories by drag and drop, and estimates in story points.
*It has a relatively rich user interface with drag and drop capability in several places.


===Very High Level Languages (VHLL)===
=====Weaknesses=====
Very High Level Languages, also known as executable specification languages, are languages with very high level of abstraction. They are somewhat difficult to capture precisely and may lead to software reuse that is very specific to specialized domains. However, the recent advent of [http://en.wikipedia.org/wiki/Domain_specific_languages Domain Specific Languages] (DSLs) and good support for them in dynamic languages (ruby, python, clojure, ...) and can be seen as promoting and helping building VHLLs.
*The story card layout would make it difficult to rank a large product backlog.
*Some features are not intuitive. Drag and drop works in some places but not in others, even though the mouse cursor make it seem that drag and drop should work. The right-click context menu is not obvious, but it's easy to use once you discover it.
*IceScrum is not suitable for large projects with multiple teams working on a single product; only a single release and single sprint can be active at one time.


== Best practices <ref name = best_practices />==
===Agilo<ref name = agilo/>===
Here are some of the best practices to be followed to make sure that the code that is being written is reusable.
[[File:Agilos.png|thumb|Agilo's Sprint Backlog view|upright=1.25]]


* The first consideration is to write code that uses a consistent naming convention, that is formatted properly, and that contains useful comments.
=====Overview=====
* Examine the code to make sure that all the procedures have a single, specific purpose. Make sure that the procedure can be describedin a short, plain sentence. For example, "This procedure accept two numbers and calculates the product of those two numbers". If a procedure can not be described simply and clearly in a sentence, then it probably does too many things. Break down complicated procedures into smaller ones that do one thing each. Procedures should contain only code that clearly belongs together.
*Each deployment can have multiple milestones (releases). The backlog contains requirements, [http://en.wikipedia.org/wiki/User_story user stories] and tasks. These three item types support a hierarchy by reference: requirements can reference stories, and stories can reference tasks. This hierarchy is difficult to establish and utilize, however. Agilo has a separate backlog for defects, which makes it difficult to prioritize defects relative to [http://en.wikipedia.org/wiki/User_story user stories]. It also has a separate impediment backlog.
* Avoid making specific reference to named application objects.
*Users can be given the roles of Scrum Master, Product Owner, or Team Member. Users may also be grouped into teams.
* Try to minimize the number of arguments in a procedure and pass in only what is actually required by the procedure. In addition, make sure the procedures use all the arguments passed to them.
*Agilo includes an excellent and intuitive task board/whiteboard view of the iteration, allowing tasks to be dragged and dropped. This is by far the best feature of the tool; other features are less untuitive.
* Group related procedures and the constants they use together in the same module, and where appropriate, consider grouping related procedures together in a class module with a clearly defined interface.
*Agilo has a simple dashboard with a sprint burndown chart, a graph of stories and tasks (total, planned, and closed), and allocation of tasks to team members by percent. In addition, it allows custom queries and reports to be created and saved.
* Keep procedures in standard modules and not in modules behind forms or documents. The code in form modules should be only the code that is tied directly to the form itself and the code required for calling general procedures stored in standard modules.
* Communicate between procedures by passing data as arguments to the procedures. Persist data by writing it to disk. Avoid using a procedure to write to a global variable so another procedure can read data from that global variable. Avoid communicating with another procedure by passing data out of the application, for example, using one procedure to write data to a disk file so another procedure can read that data.


== Advantages <ref name = history_pros_cons/>==
=====Strengths=====
* '''Efficiency''' - Software reuse increases the software productivity and decreases the time required for the development of a software by reducing the time spent in designing or in coding
*Excellent task board/whiteboard iteration view with drag and drop functionality.
* '''Standardization''' - By using the technique of software reuse, a company can improve software system interoperability and needs less people for software development. This provides a competitive advantage for the company and helps to produce better quality software and standardized software.
*Supports absolute ranking of stories by drag and drop, and estimates in story points.
* '''Consistency''' - Reuse of UI [http://en.wikipedia.org/wiki/Software_widget widgets] in MacOS and Win32 leads to common “look-and-feel” between applications
*Good reporting features, including user-customized reports that can be saved.
* '''Debugging''' -
* '''Reliability''' - Systems that incorporate a high level of reusable components are more reliable and more easily constructed. Reused design/code is often tested design/code.
* '''Profit!''' - Software reuse technique helps the company to reduce the costs involved in software development and maintenance.
* '''Reduced Risk''' - Software reuse also reduces the risk involved in software development process.
* '''Component Market''' - Reuse can lead to a market for component software. Real-world examples: [http://en.wikipedia.org/wiki/Activex ActiveX] components, Hypercard stacks, Java packages, even software tools, such as xerces and xalan from xml.apache.org (they are often included in other software systems)


== Trade-offs for code reuse at various levels of components <ref name=trade_offs/>==
=====Weaknesses=====
Different types of application code require varying levels of investment to achieve successful reuse
*Some features are not intuitive. It feels like Trac didn’t support agile concepts very well so they had to be force-fit into Trac’s model.
*When creating a task, it can be associated with a sprint, but not with a story.
*Many operations require lots of clicks to complete.


* Reusable GUI objects reduce development time and improve quality and consistency but provide only modest payback in terms of overall application development costs.
===eXplainPMT<ref name = explainpmt/>===
* Server-side components that constitute reusable business logic can provide significant payback but require extensive up-front analysis and design. They also require an architectural foundation but may experience a short shelf life.
[[File:explainpmt.png|thumb|eXplainPMT's Backlog|upright=1.25]]
* Infrastructure components and services frameworks are generic services for transactions, messaging, security, and [http://en.wikipedia.org/wiki/Database database] connectivity. They eliminate the need to repeatedly build infrastructure that all applications use, but require extensive analysis and design, and complex programming. These standards-based components can often be purchased off-the-shelf.
* High-level patterns allow organizations to achieve design reuse and identify components with high reuse potential, but developers must build or acquire the components.
* Packaged applications provide the only guaranteed form of reuse, letting user companies acquire functionality for significantly less than the cost of building it themselves. However, these applications may not offer the exact functionality an organization needs; the subsequent customization that's required will add to the cost.


== Practical problems <ref name = history_pros_cons/>==
=====Overview=====
Although software reuse provides many benefits for the developers, there are some disadvantages.  
The highest level construct is the project, and eXplainPMT supports multiple projects. Each project has one or more releases, and iterations. Note that iterations are associated with projects, not with releases. A project has one backlog, and a backlog contains stories. Stories have tasks and acceptance tests, and can be assigned to a release. Stories may also be associated with an initiative, which is somewhat like an epic, except initiatives cannot be ranked or prioritized. Surprisingly, tasks do not have estimated or actual hours; they have only two states: incomplete or complete.


=== Disadvantages for developers who reuse the code ===
Users in eXplainPMT do not have specific roles; all users are the same. Users may be grouped into teams.
* Mismatch - Reused code or design may not completely match the situation, in that case, reusing the code may incur additional time and effort.
* Non-functional characteristics of code may not match the situation - Consider a database that can scale to 10,000s of items, but you need it to scale to 100,000s of items.
* Expense - Some components may be too expensive for the project’s budget. For instance, [http://en.wikipedia.org/wiki/SGML SGML] (a precursor to [http://en.wikipedia.org/wiki/Html HTML] and [http://en.wikipedia.org/wiki/Xml XML]) tools sell for 5000 dollars a license!


=== Disadvantages for developers who develop reusable code ===
Viability, Support & Documentation
* Building reusable objects requires extensive analysis and design. The developer needs to understand and take into consideration all the generalities while coding the reusable module.
 
* The developer needs to invest extra time in testing and [http://en.wikipedia.org/wiki/Quality_assurance quality assurance], optimization, and documentation. All this takes time and labor, which increases the cost of the code.  
eXplainPMT has no user guide and only a brief README file for an installation guide. It has no forums, nor any email support. It is unclear whether development is still active; the last update was November 2008.
* IT departments must also add to the payback equation the cost of tools to support reuse, such as version control and repositories.  
 
* The cost of administering an ongoing reuse program must be considered.  
=====Strengths=====
With all these elements, it becomes apparent that reuse doesn't come cheap.
*Intuitive interface.
*Supports the definition of acceptance tests for stories.
 
=====Weaknesses=====
*Cannot estimate or track task hours!
*No task board/whiteboard view.
*No iteration burndown chart.
*No releases or roadmap.
*Development status is unclear; the last update was November 2008.
*Support and documentation are almost non-existent.
*Not suitable for large projects since it allows only one iteration to be active at a time.
 
===XPlanner<ref name = xplanner/>===
[[File:xplanner.png|thumb|XPlanner's Story view|upright=1.25]]
 
=====Overview=====
The highest level construct is the project, and XPlanner supports multiple projects. It does not include releases. Each project has one or more iterations. It does not include a product backlog, but a workaround is to create a special iteration to use as a product backlog. Iterations contain stories, and stories contain tasks. Tasks may be of type feature, debt, defect, ftest (functional test), atest (acceptance test), or overhead. Stories are estimated in hours, and tasks are estimated and tracked in hours.
 
Users in XPlanner can be assigned four permission levels: Viewer (read only), Editor, Admin., or Super Admin. XPlanner does not have a team construct for grouping users.
 
=====Strengths=====
*Intuitive interface.
*Rich built-in reports and charts.
*[http://en.wikipedia.org/wiki/SOAP SOAP API] for integration.
*Customizable notation for simple URL linking with external systems such as defect tracking.
 
=====Weaknesses=====
*No releases or roadmap.
*No task board/whiteboard view.
*No story points.
*No "epics" or hierarchy of stories/features/requirements.
*The project is dormant, with the last update in May 2006.
*Support is very limited since the project is dormant.
 
===Quick Comparison===
<table border=2>
  <tr>
    <th>'''        '''</th>
    <th>'''Agilefant'''</th>
    <th>'''IceScrum'''</th>
    <th>'''Agilo'''</th>
    <th>'''eXPlainPMT'''</th>
    <th>'''XPlanner'''</th>
 
  </tr>
  <tr>
    <td>''User roles''</td>
    <td>None</td>
    <td>PO, SM, Team Member, Stakeholder, plus custom roles.</td>
    <td>SM, PO, Team Member.</td>
    <td>None</td>
    <td>Viewer, Editor, Admin, Super Admin.</td>
  </tr>
  <tr>
    <td>''Reports''</td>
    <td>Timesheets only</td>
    <td>None</td>
    <td>Can save customized reports</td>
    <td>None</td>
    <td>Extensive built-in reports, but no custom reporting</td>
  </tr>
<tr>
    <td>''Integration & API(s)''</td>
    <td>None</td>
    <td>None</td>
    <td>SVN, trac, mylyn</td>
    <td>None</td>
    <td>SOAP, notation for URL linking</td>
  </tr>
<tr>
    <td>''Pros''</td>
    <td>Rich feature set. Timesheet feature.</td>
    <td>Rich feature set. Good task board view. Planning poker feature</td>
    <td>Great whiteboard view</td>
    <td>Intuitive</td>
    <td>Intuitive. Rich charts and reports built in</td>
  </tr>
<tr>
    <td>''Cons''</td>
    <td>No task board view</td>
    <td>Not always intuitive. Not suitable for large projects</td>
    <td>Some common actions require lots of clicks</td>
    <td>No support or forums. Status uncertain. No hours for tasks. No sprint burndown</td>
    <td>Inactive and Not supported. Not suitable for large projects. Doesn’t directly support releases/roadmaps.</td>
  </tr>
</table>
 
==Examples of proprietary Scrum Tools==
Here are some of the examples of proprietary scrum project management tools -
 
===IBM Rational Team Concert<ref name = IBM_RTC/>===
[[File:rtc.png|thumb|Planned Items View|upright=1.25]]
 
=====Concepts=====
IBM Rational Team Concert is built on the [http://en.wikipedia.org/wiki/Jazz_%28computer%29 Jazz Platform], an extensible technology platform that helps teams integrate tasks across the software life cycle.
Rational Team Concert is built on a client-server architecture and it enables software development teams to track all aspects of their work, such as work items, source control, reporting, and build management, in a single product. Rational Team Concert integrates with several other products, including Subversion, Git, and IBM Rational ClearCase revision-control products, IBM Rational ClearQuest and JIRA change management products, IBM Rational Quality Manager and HP Quality Center quality management systems, and IBM Rational Build Forge, Hudson, CruiseControl, and Maven build and process automation tools.
Rational Team Concert has an Eclipse-based client interface, a Microsoft Visual Studio client interface, and a Web interface. Additionally it provides since version 4.0 a windows shell integration within the Windows Explorer for source control of files within the Rational Team Concert repository. The client interfaces provide an integrated development environment for developers to build and deliver artifacts. Users can use the Web interface to administer servers and projects, access project areas, browse repository information, update tasks, or read about recent events.
 
=====Strengths=====
 
* User friendly interface
* Does a great job with managing changesets
* It integrates the support lifecycle into the rest of the Agile development process
 
=====Weaknesses=====
 
*Cannot use it free of charge anymore
*It's license is pretty expensive.
 
===JIRA<ref name = Jira_wiki/>===
[[File:jira.png|thumb|Jira's Dashboard View|upright=1.25]]
 
=====Concepts=====
JIRA is a proprietary issue tracking product, developed by Atlassian, commonly used for bug tracking, issue tracking, and project management. The product name, JIRA, is not an acronym but rather a truncation of "Gojira", the Japanese name for Godzilla.It has been developed since 2002.
JIRA is a commercial software product that can be licensed for running on-premises or available as a hosted application. Pricing depends on the maximum number of users, with approximately $50 per user for in-house and $7 per month per user for the hosted version being typical prices.
Atlassian provides JIRA for free to open source projects that meet certain criteria, and organizations that are non-profit, non-government, non-academic, non-commercial, non-political, and secular.
For academic and commercial customers, the full source code is available under a developer source license.
Starting with JIRA 4, a 10-user starter license costs $10 with all proceeds benefiting Room to Read.Starter licenses are also available for other Atlassian products that can integrate with JIRA, such as Bonfire, Confluence, Crucible, GreenHopper, Bamboo, FishEye and Crowd.
 
=====Strengths<ref name = Jira_mozilla_wiki/>=====
 
*Like Agile bench, Jira seems very usable and very straightforward
*Jira includes Grasshopper, a tool that provides features useful to Scrum teams. Grasshopper provides a product backlog, sprint backlogs, a burndown chart, and various other statistics.
 
=====Weaknesses=====
 
*Jira is not free
 
===Mingle<ref name = Mingle/>===
[[File:mingle.png|thumb|Mingle's Sprint View|upright=1.25]]
 
=====Concepts<ref name = Mingle_scrumtools/>=====
Mingle and Mingle Plus are a proprietary project management and collaboration platform that is built by ThoughtWorks Studios, the software division of ThoughtWorks. Mingle and Mingle Plus provide ways for a team to share information about a project and as a system of record and management for the project itself. Mingle and Mingle Plus show the status and progress of project tasks on drag and drop Card Walls that are meant to simulate an Agile Story Wall, has wikis for project collaboration, and can associate instant messages with project tasks through a feature Mingle calls Murmurs. Mingle and Mingle Plus can generate burn-down charts showing work remaining, velocity charts showing actual versus expected progress, and pivot tables for grouping data by one or more attributes.
Mingle Plus plus features include: Create visual, interactive timelines to communicate your organization's plans and goals. Collaborate to plan work towards common objectives. Track progress towards goals, understand the current status of projects and objectives. Forecast completion dates based on project work. Understand when forecasts differ from plans. Replan and adapt to change. Get alerted when objectives may be delivered later than expected. Understand which projects and work items are at risk. Work together to resolve issues.
 
Mingle and Mingle Plus are intended to support various flavors of Agile like XP, Scrum, Agile Hybrid. Though primarily a project management tool, it also provides bug tracking, project reporting and program management capabilities.
 
=====Strengths=====
 
*Although creating a project from the scratch on Mingle can be a tough task, there is a Scrum project template ready to be used.
*It’s also possible to create custom properties for each type of release so one can define all kinds of information one needs for your items and these properties can also be an aggregation of properties from the level below.
*The project structure on Mingle can be totally customized even with more than one structure in the same project, here called card trees.
*The Sprint backlog tab is good for the daily meeting and emulates the taskboard, the drag and drop feature really helps to create an immediate link to the mechanics of a taskboard on the wall.
 
=====Weaknesses=====
 
*There are a lot of customizations and expansion points but they are not really accessible.
*The feeling is that without the templates it would need a lot of work to create something really useful for a Scrum team.


== Conclusion ==
== Conclusion ==
The only way you can avoid code depreciation is through reuse but you need to be disciplined and follow a strict process. Reuse enables you to do more with less.


==See also==
To summarize, a tool for distributed teams helps improve communication and increase stakeholder visibility into the project. There are many open source and proprietary scrum tools available in the market. A team can decide on which scrum tool to select depending on the requirements.
*[http://en.wikipedia.org/wiki/Don%27t_repeat_yourself Don't repeat yourself]
 
*[http://en.wikipedia.org/wiki/Single_Source_of_Truth Single Source of Truth]
==See Also==
*[http://en.wikipedia.org/wiki/International_Conference_on_Software_Reuse International_Conference_on_Software_Reuse|ICSR]
 
*[http://en.wikipedia.org/wiki/Language_binding Language binding]
* http://agilescout.com/best-agile-scrum-tools/
*[http://en.wikipedia.org/wiki/Reuse_metrics Reuse metrics]
* http://www.agilebuddy.com/
*[http://en.wikipedia.org/wiki/Software_framework Software framework]
* http://www.versionone.com/scrum-tools/
*[http://en.wikipedia.org/wiki/Type_polymorphism Type polymorphism|Polymorphism]
* http://borisgloger.com/2009/01/21/scrum-tools-projectcards-review/
*[http://en.wikipedia.org/wiki/Virtual_inheritance Virtual inheritance]
* http://borisgloger.com/2009/04/06/scrum-tools-scrumninja-review/
* http://borisgloger.com/2008/11/15/scrum-tools-scrumy-pro-review-update/
* http://borisgloger.com/scrum/scrum-flow/


== References ==
== References ==
<references>
<references>


<ref name = techniques> http://www.revision-zero.org/reuse</ref>
<ref name = Examples_of_open_source_scrum_tools> http://www.openlogic.com/wazi/bid/188152/Comparing-Open-Source-Agile-Project-Management-Tools</ref>
<ref name = definition_software_reuse> http://www.biglever.com/papers/Krueger_AcmReuseSurvey.pdf </ref>
<ref name = Scrum> http://en.wikipedia.org/wiki/Scrum_(development)</ref>
<ref name = history_pros_cons> http://www.cs.colorado.edu/~kena/classes/3308/f04/lectures/lecture10.pdf </ref>
<ref name = Selecting_the_tool> http://toolsforagile.com/blog/archives/160/agile-project-management-tool-evaluation-guide</ref>
<ref name = wiki_code_reuse> http://en.wikipedia.org/wiki/Code_reuse </ref>
<ref name = simple_scrum_tools> http://www.agilemodeling.com/essays/simpleTools.htm</ref>
<ref name = trade_offs> http://www.informationweek.com/708/08iuhid.htm </ref>
<ref name = iterative>http://en.wikipedia.org/wiki/Iterative_and_incremental_development</ref>
<ref name = best_practices> http://msdn.microsoft.com/en-us/library/office/aa189298%28v=office.10%29 </ref>
<ref name = agilefant>http://www.agilefant.org/</ref>
<ref name = Object_orinetation> http://en.wikipedia.org/wiki/Object-oriented_programming </ref>
<ref name = icescrum>http://www.icescrum.org/</ref>
<ref name = generators> http://en.wikipedia.org/wiki/Generative_programming </ref>
<ref name = xplanner>http://www.xplanner.org/</ref>
 
<ref name = agilo>http://www.agile42.com/cms/pages/agilo/</ref>
<ref name = explainpmt>http://github.com/explainpmt/explainpmt/tree/master</ref>
<ref name = Jira_wiki> http://en.wikipedia.org/wiki/JIRA</ref>
<ref name = Jira_mozilla_wiki>https://wiki.mozilla.org/Scrum/Tools</ref>
<ref name = IBM_RTC>http://en.wikipedia.org/wiki/IBM_Rational_Team_Concert</ref>
<ref name = Mingle>http://en.wikipedia.org/wiki/Mingle</ref>
<ref name = Mingle_scrumtools>http://borisgloger.com/2008/08/26/scrumtools-mingle/</ref>
</references>
</references>

Latest revision as of 19:22, 1 November 2012

Scrum Tools - This page gives survey of the tools that can be used for practicing scrum. It considers the features offered by each of them, the scenarios in which each of them can be used considering what features it has and what features it lacks, cost involved etc.

Overview <ref name = "Scrum" />

Scrum

Scrum is an iterative and incremental agile software development<ref name = "iterative" /> method for managing software projects and products or application development. Scrum focuses on project management institutions where it is difficult to plan ahead. Mechanisms of empirical process control, where feedback loops that constitute the core management technique are used as opposed to traditional command-and-control oriented management. It represents a radically new approach for planning and managing projects, bringing decision-making authority to the level of operation properties and certainties.

Scrum Tools

Scrum can be implemented through a wide range of tools. Many companies use universal tools, such as spreadsheets to build and maintain artifacts such as the sprint backlog. There are also open-source and proprietary packages dedicated to management of products under the Scrum process. Other organizations implement Scrum without the use of any tools and maintain their artifacts in hard-copy forms such as paper, whiteboards and sticky notes.

Selecting The Right Tool <ref name = Selecting_the_tool/>

Here are some of the factors which should be considered before selecting the correct scrum tool -

Primary Factors

  • Does the tool improve visibility?

- Scrum requires transparency to succeed. Everyone who needs to know about the project from the developers to the stakeholders and maybe even the customer should be able to use the tool. There is no point using a tool if only a Scrum Master or a few people can use it and everyone else has to rely on email.

  • Does the tool improve communication?

- Tools can be used to open up channels of communication. For example, allowing a developer to comment on a user story and have a remote customer reply back – setting up direct communication between developer and customer and bypassing all the bureaucracy in the middle.

  • Does the tool reinforce trust?

- Example: A team member forgot to update the estimate for Friday. He remembers on Monday. Can you set the estimate for Friday on Monday? In a “high trust” tool like pen & paper: you can just pick up a pen and redraw the burndown. In a “low trust” tool, you cannot do this because it is considered as meddling with the past recorded history of actions.

  • Does the tool adapt to the way you work?

- Each team is going to use the tool differently. Some tools adapt to the way you work, other tools force you to work the way the tool is setup. Because of the self-managed nature of scrum, it is important that the tool support the team, and the team should not have to change their working to fit the tool.

Secondary Factors

  • Standalone, monolithic or integrated :

- Standalone tools let you create users, stories, iterations and tasks and generate some reports like burndown or velocity. Basic, but useful when you want something simple.

- Integrated tools do only project management, but they can integrate with external tools like other bug tracking tools, source control, wikis and so on. For example, you will be able to synchronize bugs from the bug tracker to the PM tool or link tasks in the tool with code commits and so on. They can provide an overview across multiple tools in use.

- Monolithic tools support the entire life-cycle like document management, bug tracking, artifact management over and above standard PM functionality all within a single tool. Advantages of monolithic are that all components are tightly integrated. Disadvantage is that you have to discard all your existing tools to move to a monolithic one. Also if the monolithic tool does not support a particular component (like continuous integration or code analysis) you may still have to use multiple tools.

  • Usability :

- How usable is the tool? When you have poor usability, people may resent working with the tool and might start working around the tool instead. Tools with poor usability may also call for additional unplanned expenditure in training and support. You also have issues of general resentment by the team at whoever foisted the tool upon them.

  • Pricing model :

- Is the tool open source, free or commercial? For commercial tools, it the pricing per-user or per-project? Subscription or one-time payment? What is your risk exposure should the team size or number of projects increase? What is the total cost of ownership, including training, support, customizations etc. How does it fit your budget?

Low Tech Scrum Tools<ref name = simple_scrum_tools/>

  • Index cards :

- The eXtreme Programming (XP) community swears by the use of standard index cards for a wide variety of modeling techniques, and in particular Class Responsibility Collaborator (CRC) modeling.

  • Post-It notes :

- Post-It notes are also an option, for example one can develop an abstract/essential user interface prototype using Post-Its on large sheets of paper. This is part of a technique called essential user interface modeling.

  • Paper :

- Pieces of paper, or index cards, tacked onto a whiteboard and connected by strings can be used for a wide variety of models. For example the individual sheets of paper can represent database tables and the lines relationships between tables on a physical data model, or the sheets can represent screens and the strings navigation flows between screens on a user interface flow diagram, or the sheets can represent use cases and actors and the strings represent associations between them on a UML use case diagram.

  • Plain old whiteboards (POWs) :

- A whiteboard for sketching on is likely the most common modeling tool in use. A digital camera can easily make copies of sketches that one wants to keep.

Examples of Open Source Scrum Tools<ref name = "Examples_of_open_source_scrum_tools" />

Here are some of the examples of open-source scrum project management tools -

Agilefant<ref name = agilefant/>

Agilefant's Development Porfolio
Overview

Products are the highest level construct, and each deployment may have multiple products. Each product may have one or more projects, which are essentially releases. Each project may have one or more iterations. Each product, project (think "release"), and iteration has its own backlog, which contains stories. Stories can be moved to any other backlog, for example from the product backlog to an iteration backlog. Stories may consist of zero or more tasks. Projects can be prioritized in the Portfolio view.

The tool supports multiple concurrent iterations, which allows larger organizations to use the tool effectively.

Agilefant supports multiple users and users can be grouped into teams. However, it does not support any user roles; a user is a user, with no differences in permissions or access to features. Teams can be assigned to specific iterations.

Version 1.6.2 does not include the concept of higher-level features or epics, although this feature is promised in version 2.0 which is supposed to be released soon. It does support the concept of themes, which are an attribute of stories, and this does provide a simplistic way to associate a group of stories.

Strengths
  • Rich feature set.
  • Usability - Agilefant is intuitive.It lacks “drag and drop” features, but it otherwise makes good use of client-side features that make the user interface more responsive.
  • Suitable for larger organizations and projects, except for the lack of “epics” or story hierarchies. (Version 2.0 should fix that shortcoming.)
  • Reasonably intuitive and easy to use.
  • Portfolio planning feature.
  • Timesheet feature.
Weaknesses
  • Stories can be estimated in hours only, not points.
  • Stories cannot be ranked absolutely; they can only be prioritized on a scale of 1 to 5.
  • No “drag and drop” re-ordering of stories.
  • No “epics” or hierarchy of stories. Note that a story hierarchy is promised for version 2.0.
  • No “task board” or “whiteboard” view.
  • No differentiation between user roles.

IceScrum<ref name = icescrum/>

IceScrum's Product Backlog view
Overview

Products (also called projects in some places) are the highest level construct, and each deployment may have multiple products. Each product has a single backlog and a roadmap. A backlog contains features (similar to epics), user stories, defects and technical stories. A roadmap contains multiple releases, each of which has a single release plan. A release plan consists of multiple sprints. Each sprint contains stories, which in turn contain tasks and acceptance tests. Impediments can be tracked for each product.

Unlike Agilefant, IceScrum includes a task board/whiteboard view of the iteration, allowing tasks to be dragged and dropped. It also allows drag and drop ranking of user stories in the backlog. Many options are available only from a right-click context menu, which isn’t obvious at first but is easy to use once you notice it.

IceScrum is the only product reviewed that has a planning poker feature. This feature allows a distributed team to play planning poker for estimating features and user stories.

IceScrum allows only a single release and single sprint to be active at one time (for a particular product), making it unsuitable for larger organizations that need multiple concurrent sprints with multiple teams running in parallel for a single product.

IceScrum users may have any of the Scrum roles (Product Owner, Scrum Master, Team Member, Stakeholder) plus custom roles may be created. It does not allow users to be grouped into teams.

Beyond a burndown chart, IceScrum does not have any reports or reporting API.

Strengths
  • Rich feature set.
  • The Sprint Backlog view resembles a physical task board quite effectively.
  • The Roadmap, Release Plan and Sprint Plan views support multiple levels of planning.
  • Acceptance tests can be recorded for each story. A BDD-inspired template for acceptance tests is available.
  • Includes a planning poker feature.
  • Supports absolute ranking of stories by drag and drop, and estimates in story points.
  • It has a relatively rich user interface with drag and drop capability in several places.
Weaknesses
  • The story card layout would make it difficult to rank a large product backlog.
  • Some features are not intuitive. Drag and drop works in some places but not in others, even though the mouse cursor make it seem that drag and drop should work. The right-click context menu is not obvious, but it's easy to use once you discover it.
  • IceScrum is not suitable for large projects with multiple teams working on a single product; only a single release and single sprint can be active at one time.

Agilo<ref name = agilo/>

Agilo's Sprint Backlog view
Overview
  • Each deployment can have multiple milestones (releases). The backlog contains requirements, user stories and tasks. These three item types support a hierarchy by reference: requirements can reference stories, and stories can reference tasks. This hierarchy is difficult to establish and utilize, however. Agilo has a separate backlog for defects, which makes it difficult to prioritize defects relative to user stories. It also has a separate impediment backlog.
  • Users can be given the roles of Scrum Master, Product Owner, or Team Member. Users may also be grouped into teams.
  • Agilo includes an excellent and intuitive task board/whiteboard view of the iteration, allowing tasks to be dragged and dropped. This is by far the best feature of the tool; other features are less untuitive.
  • Agilo has a simple dashboard with a sprint burndown chart, a graph of stories and tasks (total, planned, and closed), and allocation of tasks to team members by percent. In addition, it allows custom queries and reports to be created and saved.
Strengths
  • Excellent task board/whiteboard iteration view with drag and drop functionality.
  • Supports absolute ranking of stories by drag and drop, and estimates in story points.
  • Good reporting features, including user-customized reports that can be saved.
Weaknesses
  • Some features are not intuitive. It feels like Trac didn’t support agile concepts very well so they had to be force-fit into Trac’s model.
  • When creating a task, it can be associated with a sprint, but not with a story.
  • Many operations require lots of clicks to complete.

eXplainPMT<ref name = explainpmt/>

eXplainPMT's Backlog
Overview

The highest level construct is the project, and eXplainPMT supports multiple projects. Each project has one or more releases, and iterations. Note that iterations are associated with projects, not with releases. A project has one backlog, and a backlog contains stories. Stories have tasks and acceptance tests, and can be assigned to a release. Stories may also be associated with an initiative, which is somewhat like an epic, except initiatives cannot be ranked or prioritized. Surprisingly, tasks do not have estimated or actual hours; they have only two states: incomplete or complete.

Users in eXplainPMT do not have specific roles; all users are the same. Users may be grouped into teams.

Viability, Support & Documentation

eXplainPMT has no user guide and only a brief README file for an installation guide. It has no forums, nor any email support. It is unclear whether development is still active; the last update was November 2008.

Strengths
  • Intuitive interface.
  • Supports the definition of acceptance tests for stories.
Weaknesses
  • Cannot estimate or track task hours!
  • No task board/whiteboard view.
  • No iteration burndown chart.
  • No releases or roadmap.
  • Development status is unclear; the last update was November 2008.
  • Support and documentation are almost non-existent.
  • Not suitable for large projects since it allows only one iteration to be active at a time.

XPlanner<ref name = xplanner/>

XPlanner's Story view
Overview

The highest level construct is the project, and XPlanner supports multiple projects. It does not include releases. Each project has one or more iterations. It does not include a product backlog, but a workaround is to create a special iteration to use as a product backlog. Iterations contain stories, and stories contain tasks. Tasks may be of type feature, debt, defect, ftest (functional test), atest (acceptance test), or overhead. Stories are estimated in hours, and tasks are estimated and tracked in hours.

Users in XPlanner can be assigned four permission levels: Viewer (read only), Editor, Admin., or Super Admin. XPlanner does not have a team construct for grouping users.

Strengths
  • Intuitive interface.
  • Rich built-in reports and charts.
  • SOAP API for integration.
  • Customizable notation for simple URL linking with external systems such as defect tracking.
Weaknesses
  • No releases or roadmap.
  • No task board/whiteboard view.
  • No story points.
  • No "epics" or hierarchy of stories/features/requirements.
  • The project is dormant, with the last update in May 2006.
  • Support is very limited since the project is dormant.

Quick Comparison

Agilefant IceScrum Agilo eXPlainPMT XPlanner
User roles None PO, SM, Team Member, Stakeholder, plus custom roles. SM, PO, Team Member. None Viewer, Editor, Admin, Super Admin.
Reports Timesheets only None Can save customized reports None Extensive built-in reports, but no custom reporting
Integration & API(s) None None SVN, trac, mylyn None SOAP, notation for URL linking
Pros Rich feature set. Timesheet feature. Rich feature set. Good task board view. Planning poker feature Great whiteboard view Intuitive Intuitive. Rich charts and reports built in
Cons No task board view Not always intuitive. Not suitable for large projects Some common actions require lots of clicks No support or forums. Status uncertain. No hours for tasks. No sprint burndown Inactive and Not supported. Not suitable for large projects. Doesn’t directly support releases/roadmaps.

Examples of proprietary Scrum Tools

Here are some of the examples of proprietary scrum project management tools -

IBM Rational Team Concert<ref name = IBM_RTC/>

Planned Items View
Concepts

IBM Rational Team Concert is built on the Jazz Platform, an extensible technology platform that helps teams integrate tasks across the software life cycle. Rational Team Concert is built on a client-server architecture and it enables software development teams to track all aspects of their work, such as work items, source control, reporting, and build management, in a single product. Rational Team Concert integrates with several other products, including Subversion, Git, and IBM Rational ClearCase revision-control products, IBM Rational ClearQuest and JIRA change management products, IBM Rational Quality Manager and HP Quality Center quality management systems, and IBM Rational Build Forge, Hudson, CruiseControl, and Maven build and process automation tools. Rational Team Concert has an Eclipse-based client interface, a Microsoft Visual Studio client interface, and a Web interface. Additionally it provides since version 4.0 a windows shell integration within the Windows Explorer for source control of files within the Rational Team Concert repository. The client interfaces provide an integrated development environment for developers to build and deliver artifacts. Users can use the Web interface to administer servers and projects, access project areas, browse repository information, update tasks, or read about recent events.

Strengths
  • User friendly interface
  • Does a great job with managing changesets
  • It integrates the support lifecycle into the rest of the Agile development process
Weaknesses
  • Cannot use it free of charge anymore
  • It's license is pretty expensive.

JIRA<ref name = Jira_wiki/>

Jira's Dashboard View
Concepts

JIRA is a proprietary issue tracking product, developed by Atlassian, commonly used for bug tracking, issue tracking, and project management. The product name, JIRA, is not an acronym but rather a truncation of "Gojira", the Japanese name for Godzilla.It has been developed since 2002. JIRA is a commercial software product that can be licensed for running on-premises or available as a hosted application. Pricing depends on the maximum number of users, with approximately $50 per user for in-house and $7 per month per user for the hosted version being typical prices. Atlassian provides JIRA for free to open source projects that meet certain criteria, and organizations that are non-profit, non-government, non-academic, non-commercial, non-political, and secular. For academic and commercial customers, the full source code is available under a developer source license. Starting with JIRA 4, a 10-user starter license costs $10 with all proceeds benefiting Room to Read.Starter licenses are also available for other Atlassian products that can integrate with JIRA, such as Bonfire, Confluence, Crucible, GreenHopper, Bamboo, FishEye and Crowd.

Strengths<ref name = Jira_mozilla_wiki/>
  • Like Agile bench, Jira seems very usable and very straightforward
  • Jira includes Grasshopper, a tool that provides features useful to Scrum teams. Grasshopper provides a product backlog, sprint backlogs, a burndown chart, and various other statistics.
Weaknesses
  • Jira is not free

Mingle<ref name = Mingle/>

Mingle's Sprint View
Concepts<ref name = Mingle_scrumtools/>

Mingle and Mingle Plus are a proprietary project management and collaboration platform that is built by ThoughtWorks Studios, the software division of ThoughtWorks. Mingle and Mingle Plus provide ways for a team to share information about a project and as a system of record and management for the project itself. Mingle and Mingle Plus show the status and progress of project tasks on drag and drop Card Walls that are meant to simulate an Agile Story Wall, has wikis for project collaboration, and can associate instant messages with project tasks through a feature Mingle calls Murmurs. Mingle and Mingle Plus can generate burn-down charts showing work remaining, velocity charts showing actual versus expected progress, and pivot tables for grouping data by one or more attributes. Mingle Plus plus features include: Create visual, interactive timelines to communicate your organization's plans and goals. Collaborate to plan work towards common objectives. Track progress towards goals, understand the current status of projects and objectives. Forecast completion dates based on project work. Understand when forecasts differ from plans. Replan and adapt to change. Get alerted when objectives may be delivered later than expected. Understand which projects and work items are at risk. Work together to resolve issues.

Mingle and Mingle Plus are intended to support various flavors of Agile like XP, Scrum, Agile Hybrid. Though primarily a project management tool, it also provides bug tracking, project reporting and program management capabilities.

Strengths
  • Although creating a project from the scratch on Mingle can be a tough task, there is a Scrum project template ready to be used.
  • It’s also possible to create custom properties for each type of release so one can define all kinds of information one needs for your items and these properties can also be an aggregation of properties from the level below.
  • The project structure on Mingle can be totally customized even with more than one structure in the same project, here called card trees.
  • The Sprint backlog tab is good for the daily meeting and emulates the taskboard, the drag and drop feature really helps to create an immediate link to the mechanics of a taskboard on the wall.
Weaknesses
  • There are a lot of customizations and expansion points but they are not really accessible.
  • The feeling is that without the templates it would need a lot of work to create something really useful for a Scrum team.

Conclusion

To summarize, a tool for distributed teams helps improve communication and increase stakeholder visibility into the project. There are many open source and proprietary scrum tools available in the market. A team can decide on which scrum tool to select depending on the requirements.

See Also

References

<references>

<ref name = Examples_of_open_source_scrum_tools> http://www.openlogic.com/wazi/bid/188152/Comparing-Open-Source-Agile-Project-Management-Tools</ref> <ref name = Scrum> http://en.wikipedia.org/wiki/Scrum_(development)</ref> <ref name = Selecting_the_tool> http://toolsforagile.com/blog/archives/160/agile-project-management-tool-evaluation-guide</ref> <ref name = simple_scrum_tools> http://www.agilemodeling.com/essays/simpleTools.htm</ref> <ref name = iterative>http://en.wikipedia.org/wiki/Iterative_and_incremental_development</ref> <ref name = agilefant>http://www.agilefant.org/</ref> <ref name = icescrum>http://www.icescrum.org/</ref> <ref name = xplanner>http://www.xplanner.org/</ref> <ref name = agilo>http://www.agile42.com/cms/pages/agilo/</ref> <ref name = explainpmt>http://github.com/explainpmt/explainpmt/tree/master</ref> <ref name = Jira_wiki> http://en.wikipedia.org/wiki/JIRA</ref> <ref name = Jira_mozilla_wiki>https://wiki.mozilla.org/Scrum/Tools</ref> <ref name = IBM_RTC>http://en.wikipedia.org/wiki/IBM_Rational_Team_Concert</ref> <ref name = Mingle>http://en.wikipedia.org/wiki/Mingle</ref> <ref name = Mingle_scrumtools>http://borisgloger.com/2008/08/26/scrumtools-mingle/</ref> </references>

Retrieved from "https://wiki.expertiza.ncsu.edu/index.php?title=CSC/ECE_517_Fall_2012/ch2a_2w7_ma&oldid=69396"