Dec 28, 2004 / Java static and condition checking

0 comments
While reading Martin Fowler's book "Patterns of Enterprise Application Architecture ", found a good way to check input parameters. This is a kind of pre-condition checking in Design By Contract methodology.
class PluginFactory...
	private static Properties props = new Properties();

	static {
		try {
			String propsFile = System.getProperty("plugins");
			props.load(new FileInputStream(propsFile));
		} catch (Exception ex) {
			throw new ExceptionInInitializerError(ex);
		}
	}
0 comments
It's obvious for me that almost all existing Agile Project Management Tools (including TargetProcess on it's current stage) do not bring many benefits to software developers. Yes, they might help to resolve some problems with remote teams, customers and project stats, but they just don't as effective as they could be. The key point is automatization. I am not sure that most agile teams like the automatization provided by agile pm tools. Many agile teams like simple tools (me too). Big whiteboards and walls with big charts, cards, and all the other staff like that. Why did they want to use any Agile Project Management Tool? To move user stories description from cards into database? To have a possibility to check project status online? To assign tasks via fancy web interface? I don't think so. This will not speed up the team, so they'll likely decide to not use Agile Project Planning Tool unless they'll have to. For example, project stakeholders want more formal reports about project state. Or maybe two of six developers far far away from the rest of the team. Yes, these circumstances will FORCE team to use a tool like VersionOne or TargetProcess, but the team likely will not WANT to use the tool. So I think that planning and tracking features resolve just several secondary problems, but, in general, do not help to plan and track project. Yes, people are different, and some of them like using web-based application instead pencil and paper, so agile pm tools have they place. But I still think that these tools provide a little of benefits having the following disadvantages:
  • they might reduce voice communication in the team (but may not, this depends)
  • they usage may take additional time (how about bugs? learning curve?)
  • they always have limited functionality thus restricting team creativity about planning and tracking. For example, team invented very cool report format for project progress state, but they couldn't create it in the current tool.
  • sometimes they cost pretty much. Maybe it is better to upgrade all workstations? At least this will boost performance for sure.
Let's take a look at possible advantages (we'll suggest that team is co-located and it don't forced by customer or top management to use any planning tool).
  • all requirements are in a single place. PM and customer might feel safer in this case.
  • team have a possibility to easily track time spent on each user story and create a better estimate (however, I don't think that time tracking is always a good idea, but sometime it is).
  • a little automatization (velocity calculation, user stories sorting by business value, release date estimation).
  • project history tracking. It's useful to analyze previous projects to identify issues, but more better solution is just ask someone from the team that worked on that project.
Maybe there are some other benefits, but I doubt that they are very important. It seems that disadvantages have greater weight... So agile teams likely do not stick to web-based tool. Ok. For now we've found two cases when agile project management tools are useful, but really helpful tool should simplify and automatize some routine processes. Let's imagine what could it be. For example, tool may shipped with very cheap printer of A2 format and allows to easily print BVC (well, I guess how much you'll spend on paper :). Or it can be shipped with pretty cool device that will automatically print out user stories' cards (card format must be changeable). Any other ideas? Yes, good scanner with hand-written text recognition app, so you'll just put all cards into special device and within 5 minutes you'll have all the cards in the database (Wow! I'm already loving this device). Well, enough for now. I see that all the ideas above are pretty similar. They all help to convert electronic data (database) into physical format (paper) or vise versa. It is required to say that there are two viable possibilities for agile project planning:
  1. Use almost only paper and big boards
  2. Use almost only software application
The third approach is to use both, but in ANY case this WILL take additional time to convert data from one format to another. And these formats VERY different, so there is no easy way for automatic convertion. In fact, software agile project management tools force teams to not use simple original tools. And this is the main problem. It can't be resolved easily and quickly. All possible solutions are expensive and a little bit crazy I think. But why quite many agile project management tools have been appeared during the last several months? I don't know. Maybe their creators have clear vision and could answer this question better. Could agile project management tools bring more benefits? Yes, they could. Some thoughts about possible ways will be discussed in the next article.

Dec 2, 2004 / TargetProcess under open source license?

10 comments
I'll share some thoughts about TargetProcess future here. The existing version is free for now (don't worry, it will be always free :), but it is planned to release next version as a commercial product. We just should make some money to survive. I like open source. And the commercial release will be shipped with source code. But I wonder if the free "light" version could be released under an open source license. Will anyone improve the system? How much effort additional coordination will take? Will anyone buy commercial version while there is already free edition that could be improved? As you could see, I have some doubts. What do you think? I am especially interested in whether anyone wants to make some improvements? There is a chance that TargetProcess will turn to an open source project, but I am not sure for now. Post your comments to influence my opinion.

Dec 1, 2004 / Iteration Velocity's and User Story Effort's Units

2 comments

I don't know how people could estimate User Stories' effort in any time-independent units. I read that someone measure effort in "green frogs" or "pink bunnies", but I really don't understand how they could completely abstract they mind from time units. Days, hours or weeks are so natural that I wonder why I should use abstract (well, but funny) units. I stick to ideal day. Load factor is just bad in many cases and does not bring anything interesting. Ideal days are good and easy to understand. I can imagine and estimate how much work I could accomplish within a single ideal day. No interruption, no coffee breaks, great mood and so on. So I estimate User Stories in ideal days. I believe that precision is much better in this case. However, there are some problems. The major one is that my ideal day is not the same as others' ideal days. For example, I may complete the "Tricky business rule implementation" story within 4 ideal days, Bob will complete it within 3 ideal days, and our super-developer Joe will get it done within 1 day. So my estimates will be completely invalid if User Story will be assigned on Joe. Do you think I must stop estimating? Maybe I should change the rules, try to use "average developer's performance", invite cool consultant and start to count Functional Points? Right? Wrong! In reality I DON'T CARE about individual performance difference. I won’t emphasize that Bob three times slower than Joe. I won’t break the team. I just measure team velocity (or iteration velocity), since Joe will always do about the same amount of work, and Bob will do about the same (but different) amount of work as well during one iteration. The main idea is that effort units and assumptions for estimation must remain the same during the whole project. So if I chose My Ideal Day as the velocity unit, I must estimate all user stories on my ideal day basis. Always.

That’s all. Yes, estimation in agile project may be that simple :) And to measure effort in "green frogs" I should just say that my ideal day equals to one green frog.

Subscribe to the RSS feed
Stay tuned by having the latest updates via RSS
Follow TargetProcess on Twitter
Get in touch with our team

TargetProcess is an agile project management tool. It is designed to solve distributed teams problems and support agile development processes.



Key Features

  • Full Agile Project Management Support (Scrum, XP, Custom)
  • Productivity Tools (Tp.Tray, ToDo list, dashboards, Inline editing)
  • Customizable Development Process
  • Subversion Integration
  • Integrated Bug Tracking, Help Desk, Time Tracking

Get TargetProcess for Free (5 users pack)

Previous Posts



    follow me on Twitter

    Archives