Choosing open source / free Scrum tools

I would like to have a free Scrum tool which have these features for planning & progress reporting:
• virtual task board (to show which user stories in the current sprint / sprint plan, release plan)
• burndown chart
• backlog (prioritized list of user stories)
• velocity chart
• Gantt chart / iteration timeline

I found at least 2 tools that fulfill those criteria:
• Icescrum http://www.icescrum.org/
• Agilo http://www.agile42.com/cms/pages/agilo/
Agilo has a better documentation than Icescrum and also offers integration with trac & svn, but you need to pay for Pro license for using the virtual board (& many other handy functions), about 800 euros for 10 users/year. So finally I decide to use the Icescrum instead. Icescrum is just a web application (a war file) that you can install for example in Tomcat. You can testdrive the icescrum here: http://www.icescrum.org/demo/

Some screenshots from http://www.icescrum.org/:

Burndown chart & activities


Virtual task board: release plan /sprint plan


Which agile/scrum tools/project management tools do you use? What are the advantages/disadvantages of those tools? Please write your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

References:

Comparing Open Source Agile Project Management Tools by Brad Swanson
http://olex.openlogic.com/wazi/2009/comparing-open-source-agile-project-management-tools/

Scrum and XP from the Trenches by Henrik Kniberg
www.crisp.se/henrik.kniberg/ScrumAndXpFromTheTrenches.pdf

Agile Estimating and Planning

Design document: to write or not to write

One of the tenets from agile manifesto says "Working software over comprehensive documentation". Unfortunately many lazy (agile) developers use this manifesto to excuse that "we don't have to write documentations at all". Some developers claim that they are agile when they follow the no-documentation principle without practicing other agile principles (such as early & frequently deliveries.)

I believe that writing simple documents (such as use-case, requirements list and architecture design) is still beneficial yet in the agile context.

There are several benefits of a written design document (whether as up-front design or during the iterations):
• you can distribute it to many people (also across the continent) to get feedbacks, so you don't have to explain again & again orally.
• To get feedbacks in the early phase while you defining architecture is important. Despite using agile process, you can't denied that the cost of changing your initial architecture decisions will get more and more expensive as you proceed in the development phase. The cost of repairing a wrong decision in the early phase (architecture) is expensive. You can get better feedback by writing the requirements & the architecture clearly in documents.
• if you don't write you can easily overlook/forgetting important details (beware: the devil is in the details), other people can review the list in your documents and add/comment.
• You can postpone some risky decisions and delay the design which most likely to change, but at least you need to mention the indecisive issues, the risks and the assumptions in your design documents, it will serve like a checklist that you/others can refer later to discuss.
• If you leave the company/project or if you delegate the project to others, the next person doesn't have to start from scratch. It will be easier also for the next people who have to extend the finished product, so they understand the reasons behind you decisions.

Please read my blog about "Software architecture design document"
http://soa-java.blogspot.com/2011/06/software-architecture-design-document.html

How about your experiences with trade-off between the rigorous (RUP) documentations & agile simplicity in your organization? Please write your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

Reference:
Agile Manifesto

How to define your team: fixed teams or project based?

We consider 2 ways to form developer/tester teams:
1. Use a fixed team that move together from one project to the next.
2. Form a new team from a developer pool each time a new project come.

In my opinion using the first approach (a fixed team) is preferable than the second (project based team).

A fixed team will be more productive since its members have learned to trust & anticipate each other (regarding competences, work styles, personalities). Besides, it's easier to measure the velocity (thus improving your estimation & planning) with a fixed team. On the other hand, you need to give time for the team to "gel", once the team spirit is formed the productivity will increase.

A scrum team facilitates itself for this fixed-team approach. The daily scrum meetings facilitate the face2face communications between team members thus strengthen the "glue" inside the team, good for bashful geeks who otherwise will hide the whole day behind his PC.

Strangely enough, my observation of the drawback of a project-based team came from outside the professional works. I can share an experience in our church music team. As one of the biggest church in the Netherland, we have lots of talented musicians in the pool. Every week we will draw a set of band members from the pool. We spend the first hours of weekly exercise struggle to blend as a new team, so less time left to build the musical quality nor to worship as a team.

As conclusion, teams are harder to build than projects so it's better to form a persistent team that move together from one project to the next.

How's about your experience in your organization (work, church/community project etc)? Please share your comments.

---

Source: Steve's blog http://soa-java.blogspot.com

Reference:
The Clean Coder by Robert Martin



Disclamer: the 'bash-ful' term in this article has nothing to do with the bash shell in Linux.

Using openSSH

Ssh/scp is more secure than telnet/rsh/rcp due to encryption and server verification through certificates. In this blog we will discuss 3 issues: how to verify that you connect to the genuine server, how to create new keys in case that your keys have been compromised and a handy method to do ssh/scp without password.

1. How to verify a server connection
The first time you tried to connect to a server using ssh, you will be asked to verify the public key of the server:
> ssh auser@aserver
The authenticity of host 'auser(ip address)' can't be established.
RSA key fingerprint is bla:16:ee:ec:0b:19:5e:0b:33:c7:9f:ef:bla:bla:bla
Are you sure you want to continue connecting (yes/no)?

Once you say yes, the public key will be saved in your ~/.ssh/known_hosts file. Bear in mind of the man in the middle attack, how can you be sure that you communicate with the genuine server? A way to check by comparing the fingerprint of the server's public key with the fingerprint stated above. The server public key is located in the /etc/ssh/ssh_host_algorithm_pub.key file. Having this file (perhaps mailed by the admin of the server) you can generate the fingerprint using 'ssh-keygen -l -f public_key_file' and compare the values with the fingerprint above.

2. How to create new keys
If you're in a situation where your server keys have been compromised, you can generate a new pair of ssh public & private keys in the server, using ssh-keygen or open-ssl for example: 'ssh-keygen -t algorithmname', substitute the algorithmname with RSA or DSA. Use ' Hostkey keyfilename' to assign this key as the new ssh key. It's a good habit to regularly renew your keys just in case that the current key has been compromised.

3. Ssh/scp without password (authentication via PKI / X.509 certificate)
It will be handy to avoid being asked to type password everytime you use scp/ssh. Here are the steps to accomplish this: generate client keys using ' ssh-keygen -t algorithmname' in ~/.ssh directory. Substitute the algorithmname with RSA or DSA. Then copy the public key to ~/.ssh/authorized_keys in the server.

---

Source: Steve's blog http://soa-java.blogspot.com

References:
Foundations of CentOS Linux by Chivas Sicam and Ryan Baclit


Man in the middle attack http://en.wikipedia.org/wiki/Man-in-the-middle_attack
Convert keys between OpenSsh and OpenSSL http://www.sysmic.org/dotclear/index.php?post/2010/03/24/Convert-keys-betweens-GnuPG%2C-OpenSsh-and-OpenSSL

Tracer bullet software development

The principle behind its name:
by tracing your bullet, you can see where it's going so that you can adjust your aim to the target better.

The steps:
• define the highlevel subsystem objects (e.g. UI client, database access layer), by all the developers in the team instead of just an architect
• the developers define the interfaces of these objects & how they communicate (e.g. via webservice)
• implement the interfaces with mock objects, integrate early (proof of concepts how the subsystem communicate)
• implement tests with user's scenarios & canned data
• implement the functional code (start with the hardest problems/new technology first), only accept working code (which not breaking the test)
• refactor & refine

SOA & spring lend themselves to this method. In the wsdl-first SOA development you inherently start with defining the interfaces (via wsdl contracts). In Spring you can start with defining the interfaces and later bring in the implementations using dependency injections.

The benefits:
• teams/developers can work in parallel
• the whole teams/developers understand the architecture
• promote communications between teams/developers
• doesn't waste time with unproven low level designs
• you can give demos to the customer earlier to get earlier feedbacks
• the application management (technisch applicatiebeheer) can test the integration between subsystems earlier thus reducing the risk that the project will be late in the product acceptation/deployment phase or that the developer need to redesign and reimplement parts of the systems.
• the QA team can test the performance & security earlier for earlier feedbacks

Source: Steve's blogs http://soa-java.blogspot.com/

Any comments are welcome :)

---

Source: Steve's blog http://soa-java.blogspot.com

References:
The Pragmatic Programmer


Ship It!

Software (architecture) design document (technische ontwerp)

Source: Steve's blogs http://soa-java.blogspot.com/

Why writing design documents:
• to communicate design decisions and why
• to document the benefits & risks of your design
• to serve as a written contract (between you, your manager, your team, product manager, client / product manager): to limit changes, #works, risks.
• to provide common terminologies
• to facilitate peer review / feedbacks from shareholders, to minimize unexpected risks by addressing them before implementing the code

---

An exhaustive table of contents:

1. doc purpose, terminology, reference, distribution list, version,

2. high level summary: purpose/problem/why, who will use, gap analysis (condition now vs advice/solution)

3. scope: benefits, assumption, risks/issues, relation with other projects/dependency, standards
4. requirements:
o use cases:
 actors
 trigger
 preconsitions
 postconditions
 priority
 level: user-goal/sub-function/summary
 frequency
 type: interactive/batch/interface
 flow (basic flow, alternative flow, error handling flow): what the user does & system response, not how/why
 data dictionary (e.g. what the user enters in the UI):
o field name
o type (input,output)
o required y/n
o format: Numeric, texts, y/n, enums
o validation
 special requests (e.g. browsers & resolutions, availability)
 storyboard: to show user expectation of system behaviour e.g. GUI information presented to the user/entered by users, actions/requests which users can perform, screenshots
o other (non-functional) requirements (e.g. performance, legal, licence, security, tools, standards, compatibility with legacy system, 3rd party, OS/environment)

5. high level design/ system architecture (4N+1+more):
o logical view: list of main elements: roles/responsibilities/interactions, architecture diagram, organization (subsystems, layers), frameworks
o design constraints: application type (e.g. web apps, webservice), architecture style (e.g. layered, domain driven, soa), technologies (e.g. languages/framework, database vendor, OS) , compatibility, dependency, corporate policies, standards
o design trade offs/rationale / use-case view / traceability, for example:





o implementation view: artifacts/executables, module/package structure
o process view (concurrency, synchronization)
o (human) business process: (can refer to use-case)
 forms: sample forms, handling
 procedures: trigger/conditions, handling-steps/order/process-diagram, data needed, business rules, expected results, time limit, error handling
o quality attributes:
 security concerns: authentications/authorization mechanism, encryption, password (min strength, expiration), database/file-system access level (read only, write)
 performance (e.g. response time, load/throughput): goal (e.g. response 5 sec with 100 sessions), degradation mode (e.g. response 5-10sec with 150 sessions), measure, correction action (e.g. if timeout then show a "please try again later" page)
 reliability: transaction/locking, validation, defect rate (e.g. product is accepted when no critical bugs left in the buglist), accuracy, recovery, restart, mtbf (max time before fail), mttr (max time to recover) , error handling, logs, troubleshooting / error code
 usability/user friendliness: resolution, browser, font/color, standardization of GUI components & terms, help/user-manual, max time to complete task, training requirement)
 maintainability/scalability: log, doc, standard, parameterization (e.g. internationalization, changing contents/config)
 availability
 reusability
o crosscutting concerns (e.g. cache, authentication, communication, exception management, log) and how to address this issue (e.g. aspect oriented programming)
o test: risk-level & tests per design aspects/requirements/usecase ,techniques/framework (e.g. selenium GUI test, jmeter stress test)
o deployment view: hardware/networks/software configuration (e.g. database, mds, firewalls, clusters, soa/clouds configuration), compatibility, protocols (e.g. https, soap), deployment-settings, configuration management (e.g. via console/file/centralised-server), installation procedure

6. low level design (e.g. for GUI/presentation layer, business classes, webservices, database layer):
for each subsystems describes:
o role/function
o artifacts (e.g. jar/war/dll), how to be used (e.g. webservice, lib, web application)
o input/output, interface (e.g. webservice or lib)
o constraints: dependency, framework
o class diagram
o sequence diagram, process view (concurrency, synchronization)
o business process diagram
o error handling
o configuration (e.g. hardware/software/version needed, wsdl)
o for UI components: screenshots, screen objects, actions, events, files/classes (templates/jsp/php), resolutions & browsers
o for data objects: how to store/datasource (e.g. database/file), process, data(class) dictionary (type, description, attributes, methods), tabel dictionary (data type, keys/contraints), data model/tabel relationship diagram, accessibility/security
o unit tests

7. planning: development schedule/time, development cost, development organisation (e.g. resources/skills-needed/roles, raportage/meetings), procurement/cost(hardware/software/tools/licence/workplace/training)

---

Tips:
• some items in the content list above are optional and can be removed due to duplications (with similar items within this document or with other documents such as statement of work/SOW, product requirement doc/PRD, plan)
• you can separate the contents to several documents for several target audiences (e.g. use case doc, PRD, software architecture doc, product acceptance plan, test plan, development plan). Personally for small projects (less than 100 thousands euros / 400 man hours) I prefer to write a single document as concise as possible (less than 20 pages) instead of writing 6 separated documents.
• you don't have to be 100% UML compliance, the diagrams are just supplements
• don't try to be perfect in the first iteration, the design document is a living document, keep your document lightweight/easy to update
• provide unique identifier for design elements (e.g. usecase, requirements) so you can refer to
• Suppose as an architect you need to write a design document for your developers, how much details should you put in your design document? The amount of design work and the formality of that work depend on two factors: the expertise of the project’s developers and the difficulty of the project. If the project has expert programmers and is a simple project, the design can be less detailed. But if the project has inexperienced programmers, uses unfamiliar or untested technology or demands high reliability, then a more detailed design approach may be warranted.

Any comments are welcome :)

---

References:
• Software Project Survival Guide by McConnell

• Microsoft Application Architecture Guide

• Applying UML and Patterns by Larman

• http://blog.slickedit.com/2007/05/how-to-write-an-effective-design-document/
• How to Write a Software Design Document by Alissa Crowe-Scott http://www.ehow.com/how_6734245_write-software-design-document.html
• RUP op maat by Dekker

How to write use cases

Source: Steve's blogs http://soa-java.blogspot.com/

How to find use cases:
1. identify the system boundary
2. identify the primary actors
3. identify the goals of the primary actors
4. define use cases to satisfy those goals

Do:
• use UI-free style e.g. the student authenticates himself
• be terse
• uml (use case) diagrams are just supplements/optional
• focus on the users/actors and their goals than tasks
• use a verb as a name

Don't:
• UI specific e.g. the student fills his name in the username-inputbox at the right corner then clicks the OK button next to this inputbox
• describe the internal workings e.g. the system then performs this sql query: select .....

Consider tests:
• boss test: is your boss happy if you do this use case the whole day?
• elementary business process: add business value
• size test: a use case is seldom a single step

Contents:
• actors
• trigger
• preconsitions
• postconditions
• priority
• level: user-goal/sub-function/summary
• frequency
• type: interactive/batch/interface
• flow (basic flow, alternative flow, error handling flow): what the user does & system response, not how/why
• data dictionary (e.g. what the user enters in the UI):
   o field name
   o type (input,output)
   o required y/n
   o format: Numeric, texts, y/n, enums
   o validation
• special requests (e.g. browsers & resolutions, availability)
• storyboard: to show user expectation of system behaviour e.g. GUI information presented to the user/entered by users, actions/requests which users can perform, screenshots

If I forget something please comments :)

Reference:
Applying UML and Patterns by Larman