We've implemented people allocation. Below some screenshots.

People load at a glance

People load details

Assigned bugs, tasks, stories.

We've almost finished web services API implementation for TP 2.3 release. It looks quite powerful and provides huge integration capabilities. With web services API you may do almost anything: add, edit and delete new entities, retrieve entities and even execute custom queries based on HQL (Hibernate Query Language). Of course you need to know HQL syntax (close to SQL in fact) and understand TargetProcess domain model to create complex queries. So we share entities description, class diagrams and NHibernate mapping files. You may check Web Services Developers Guide (PDF - 0.4M) for details.

Here are some examples that shows web services abilities.

Add new bug into TargetProcess.

BugServiceWse bugService = new BugServiceWse();
TpPolicy.ApplyAutheticationTicket(bugService, "admin", "admin");

BugDTO bug = new BugDTO();
bug.Name = "New bug";
bug.CreateDate = DateTime.Today;
bug.Description = "Bug Description";
bug.ProjectID = 1;
            
int bugId = bugService.Create(bug);

Console.WriteLine(bugId);

Add comment to existing user story.

UserStoryServiceWse service = new UserStoryServiceWse();
TpServicePolicy.ApplyAutheticationTicket(service, "admin", "admin");
int storyId = 98;

CommentDTO comment = new CommentDTO();
comment.Description = "New Comment";

int commId = service.AddCommentToUserStory(storyId , comment);

Exampe with complex HQL query. Select all user stories assigned to user

string userName = "admin";
string userPassword = "admin";
UserStoryServiceWse userStoryService = new UserStoryServiceWse();
TpServicePolicy.ApplyAutheticationTicket(
userStoryService, userName, userPassword);

string hqlAssignedUserStoryQuery =
@"from UserStory as us where us.UserStoryID in 
       (select team.Assignable.AssignableID from Team as team 
            where team.User.UserID = ? 
            and team.Actor = us.EntityState.Actor 
            and team.Assignable.AssignableID = us.UserStoryID)";
UserStoryDTO[] stories = userStoryService.Retrieve(
hqlAssignedUserStoryQuery, new object[] {users[0].UserID});

People Requests area is already implemented. People Requests is a queue of PM demands from all projects within a company. It will help top managers to make decisions about additional hiring or re-allocations.

Main functionality:

• Allow project managers to add person request for specific project
• Allow top managers to see all people requests in one place prioritized, with defined reasons and clarification
• Comment thread for each request
• Notify top manager about new person request
• Search for people requests, add custom fields

Below is a mock ups of Allocations area in TP 2.3. Any comments appreciated!

People requests management provides answer on quite tough question: "What projects need more people?". Together with Allocations area TargetProcess will provide information for some important decisions: "Could we re-allocate someone from another less important project?", "Should we hire more people?"

Today we had initial discussion about People Management area in TP 2.3 (March). Here are some initial results.

It will be possible to see allocations on all projects by person as well as set allocation end date. Total workload will be visible as well. The view below will answer very important question: who will be available for specific date? For example, new project will be started 10-Apr and it will be possible to see persons who will be free or partially free starting from 10-Apr (or earlier).

Also there may be brief allocation report that will show minimum information: projects/iterations by person, assigned effort, allocation end date and major release milestones (this report is not approved yet, so if you have comments or suggestions please go ahead).

Current iteration dedicated to clean-up and performance improvements. We'd released TP 2.1 and TP 2.2 so it is time to refactor some areas as well as improve performance.

The main thing we've done is removing Ayende Generics. With other quite specific improvements this gave significant performance boost.

Test Configuration

Test configuration is not enterprise, but rather for small/average company setup. Database and Application are on the same server which is BAD thing for large concurrent users set. In fact if your target is about 100 concurrent users in TargetProcess you should setup database and application on different servers.

Tests themselves are kinda extreme. There are three user types (Developer, QA and Project Manager). QA browse bugs and adds bugs, Developer adds comments and time and browse user stories and ToDo, PM browse different reports. There are about 20% of PM, 40% of QA and 40% of developers in test users population.

Test duration is 10 minutes and during that time about 350 bugs and 400 time records added into database (quite many as you can imagine).

Server configuration: CPU AMD Athlon 64 X2 3800+, RAM 2 GB

Results

Chart below shows average page time (sec) for TP 2.1, TP 2.2 and TP 2.3

This chart shows greater scalability of TP 2.3. Response time for 10, 20 and 30 users in TP 2.3 almost the same.

TP 2.2 or TP 2.1 did not work for 50 or 100 concurrent users (cpu usage is 100% and server almost can't process requests). TP 2.3 runs with 50 and 100 concurrent users without much problems.

CPU usage is quite good (if you bear in mind that database and IIS on the same server).

Also we've measured average CPU usage on application server when database and IIS on separate servers and it is about 50% for 100 concurrent users.