Blog

1 day ago

Agile Software Development Process: 90 Months of Evolution

Three years ago I wrote an article that describes the changes in our Agile software development processes from 2008 to 2012. Three more years have passed by and our processes were not set in stone. Here I want to provide you with 90 months of changes in our product development practices, company culture, structure and engineering practices. Hope you will find it interesting and learn from our mistakes.

Read the article: Agile Software Development Process: 90 Months of Evolution

Teams structure evolution

2 weeks ago

Targetprocess 3.7.7: Merge Duplicate Bugs or Requests

Important Notice for On-Site Customers: mashup store change

If you added your mashups using the Mashup Manager inside TP, you shouldn’t notice any differences. However, if some mashups had been put directly to the Javascript\Mashupsfolder, the administrator will have to manually move all such mashups to the Javascript\Mashups\Common folder.

Read more

Merge Duplicate Bugs or Requests

In v.3.7.2 we introduced a new Relations type called ‘Duplicate’. When on an entity view and you select any other entity to be added as a duplicate, it appears in the Outbound Relations section.

Starting with v.3.7.7 you can now merge duplicate Requests or Bugs. You’ll notice a ‘Duplicate’ list on the view, directly below the entity state. When you click the ‘Merge’ button a few things happen. First, attachments from any duplicates that are not in the final state are added to the primary entity and then any descriptions and comments will be copied as a comment tree to the primary entity. Finally, all the duplicates will then be moved to their final state, be tagged ‘merged’ and a comment with a link to a primary entity will be added. If you merge Requests, then all unique requester names will be added to a primary entity.

Duplicate-Bug

Import Assigned Team

Now if you use CSV import for adding new or updating existing Targetprocess entities then assigned Team is taken into account. It means you may do a batch update of a Team for a set of entities.

Fixed Bugs

#61327 Fixed: Comet update event (if out-of-proc) refers to a Comet server instead of  a TP application server
#90140 Fixed: Time records absent if a Role is not set for at least one time record
#106038 Fixed: unable to add a new tab to the Requester view
#106412 Fixed: top quick add context is not updated if current context is changed from the top team/project selector
#106513 Fixed comet exception “Only ITestRunItemDto instances are allowed here”
#107272 Fixed: invalid slice definition exception if visual encoding rule is applied and all cards are deselected in board settings
#107502 Fixed: The Visual Encoding tab for View Setup is broken in IE10

4 weeks ago

People Allocations Management

People Management is a very wide topic, as it touches different activities, from Portfolio Planning and Management to managing a team’s workload. There are many use cases to address and a huge amount of small things to consider, as a tool vendor. We’ve started improving this area in Targetprocess and here are the features, which we plan to implement first:

In this article we will cover the feature “People Allocations Planning”, which is currently in development and will be released quite soon.

People Allocations Planning

This feature will give us a possibility to plan people allocations on projects, taking into account their current and planned allocations, and see if any conflicts may happen. We will be able to specify what people – teams and individuals – are required for a project, how long we need them for and what % of their total working hours they can be available, and therefore visualise and manage possible over- or under-allocations.

Note: Here we talk only about a possibility to plan people allocations on projects, not taking into account how much work people may currently have or will have to complete in every project.

Project Planning

Let’s imagine we have a new project “Chocolate Factory”, which we need to plan activities for. It should be started in a month and we plan to complete it by the end of the year, so that we have plenty of chocolate by Christmas.

Let’s assume that we know how many and what people – teams and individuals – we need for this project, so that we can plan people allocations, specifying for how long we need each person and team, and what % of their total work time they should be available on our project. Let’s say that we need 2 development teams – Alaska and Utah – full time (100%) for the whole project duration, 1 designer will be needed full time in the beginning and only for 25% of his time when the project moves into development phase, and 1 PM half time for the whole project duration.

We can create and visualise all the planned people allocations on a timeline view where projects are selected as lanes and people allocations are selected as cards.

Screen Shot 2015-08-05 at 20.40.09 3

Thus, once we have started planning people allocations on a project we can easily see if the newly created allocation is in conflict with any existing allocations this person or team may have, and what projects we do conflict with. In our example we can clearly see that Alaska and Utah teams will be overloaded during a period of time, if we start projects as planned.

Screen Shot 2015-08-05 at 20.43.29

Here we have a choice to either look for other people/teams to work on our project or shift the project in time, to avoid conflicts.  We’ve decided to shift our project in time and start it later. There is risk we won’t have chocolate for Christmas, but if we overload our people in the first place, we risk to not have anything for Christmas, not even the turkey.

Screen Shot 2015-08-05 at 20.44.39 1

Now there are no more conflicts and teams and people can move from one project to another without stress.

Forecasted people overload

As Targetprocess allows to forecast a project’s possible completion date based on the linear velocity and progress, we can see possible overload and conflicts resulting from some projects taking longer than originally planned, and therefore people stuck on these projects, while they have planned to move to another project already. On the example below we see that our Chocolate Factory project is delayed and both teams are going to be overloaded as they planned to start working on the next project from November 2015.

Screen Shot 2015-08-05 at 20.47.14 3

The same information can also be made visible when you plan a project roadmap. Whenever you plan a project in time or a project is delayed and it leads to people overload, you’ll see the conflict time areas of your project highlighted.

Screen Shot 2015-08-05 at 20.57.25 2

Hovering a mouse over the red area you’ll see who exactly got overloaded as a result of current project planning and progress.

People Availability

Very often we need to answer the question ‘Whom can I invite to work in my next project?’ or ‘Who may become available at a given moment of time?’. We could answer this question by creating a visualisation where our people – teams or individuals – are selected as lanes and people allocations are selected as cards in those lanes.

AllocationsOverload

Here we can easily see if someone is accidentally overloaded or might be overloaded soon, as well as get an understanding who will become available soon for working on a new project.

On the example above we can see that Lambda Team has conflicting allocations in May, and is loaded for 120% in total. Alaska Team is 100% available starting from September though, so we can allocate them to a new project and start it in September 2015.

The same view is available for individuals. Here we zoom in to see more project details on cards.

PeopleAllocationsOverload

Allocations can be updated straight from this view via context menu:

Screen Shot 2015-08-05 at 21.11.03

People allocations start/end dates can be tied to the start/end dates of a project when we need people for the entire project duration. Initially they are tied to the project’s planned start/end dates, later when our project has been started, all allocations will become tied to the project’s real start date and will be shifted for the project’s delay. For example, if we planned to start a project a month ago, but started it only now, all the planned people allocations will be shifted for 1 month and will be tied to the project’s real start date. It will allow to quickly get all the allocations updated according to reality.

Next steps

Here are some ideas we’re considering for future implementation, and we would really like to know what you think about them and whether you need them at all:

 

We look forward to your feedback!

1 month ago

Targetprocess v.3.7.6: Improved Axes Ordering, Stacked Bar Charts

Custom Graphical Reports

Improved Axes Ordering

Starting from 3.7.6 date axes will appear in chronological order.  So reports for an ‘Iteration’, ‘Release’ or ‘Team Iteration’ will be sorted by their Start Date and reports on the ‘Build’ axis – by the Date property.

‘Entity States’ axis items are now in the same order as set in the Process Workflow.  States are now grouped and ordered in the same way for Reports, Board and List views.

376 cgr state order

Stacked bar charts

We’ve added a new type of report – a stacked bar. Now you can create a bar chart with a cumulative effect and compare the contributions of individual items to the whole value across some category.

For example, compare the effort across Releases that were completed by different Teams.

376 cgr stacked chart 2

Setup reports for ‘Time’, ‘Tag’ and ‘Assigned Effort’ categories

In v.3.7.6 we’ve also introduced the ability to build reports based on Tags, Time and Assigned Effort.

376 cgr new card

You can use the Resources Index to see what fields are available to be used in such reports.

As an example using Tags  as a source item, here is a report of the entity counts that are assigned to particular tags:

376 cgr tag report

The Assigned Effort item represents the effort assigned to a user in a particular role. For example, we can build a report to see the effort assigned to users in the Developer role.

376 cgr assigned effort report

 

Find more examples of new reports in a “Templates” tab of a Report Setup.

QA Area: Individual Test Cases order in Test Plans

As you know a test case can be linked to many different test plans. Previously a “Test Case A” couldn’t be put before a “Test Case B” in a “Test Plan B” if they were placed in a different order in a “Test Plan A”. Starting from the new version test cases may be put in a different order in different test plans and be executed accordingly.

Screen Shot 2015-08-03 at 09.25.49 5

QA Area: Clickable Last Run Results unit on a User Story view

When you need to review user story test plan run results, you can simply click a ‘Test Plan Runs’ unit on a user story view and have run results opened.

Screen Shot 2015-08-03 at 10.09.08 2

Fixed Bugs

Schedule your personal demo

Our product specialists will show you the beauty
and power of Targetprocess 3 and help you to customize
it for your process and business requirements

Request

Get your free account now

Over 6000 teams
in 50+ countries start their day with us.
Welcome on board.