MySQL Delete rows subquery You can’t specify target table ‘XXX’ for update in FROM clause

Today my colleague and I have received a gift from MySQL.
Our goal was to delete some rows obtaining them using a subquery.

Here is the query:

DELETE ps_pack FROM ps_pack
WHERE id_product_pack IN (select id_product_item from ps_pack where id_product_pack = 148356904);

And here the response of MySQL
You can't specify target table 'ps_pack' for update in FROM clause

The query is pretty easy but MySQL doesn’t want to delete rows in a table that is used in a subquery.
Looking for a solution we came across a post with the solution (unfortunately I lost the link).

Don’t ask me why but wrapping the query with some useless steps I fooled MySQL:

DELETE  p.* FROM ps_pack p
WHERE p.id_product_pack IN (SELECT  id_product_item FROM (SELECT id_product_item FROM ps_pack where id_product_pack = 148356904) x);
Pubblicato in SQL | Contrassegnato , , | Lascia un commento

Draw chart, network diagram, architectural diagram, gantt etc.

Do you have to write documentation and you need chart or flow diagram, architectural diagram, comunication diagram, gantt or something like that?
If you haven’t installed Visio these sites might help you:

Free (It allows to save your chart directly to an xml file). I like it!

Free editor (If you want to save you work you need to have an account and pay for it)

Pubblicato in Uncategorized | Contrassegnato , , , | Lascia un commento

Jira: how to set in progress status when a subtask move to in progress using Script Runner

This is something that Jira would have done by default but it doesn’t…
So If you require that the parent issue change status from TO DO to In Progress when a subtask move from TO DO to In progress, this is the solution.
Buy Script Runner that is cheap and allows you to do whatever you want.
Add a post function (script runner) to the transition of the subtask workflow.
Here is the code to add in the subtask transition post function from TO DO to In Progress

import com.atlassian.jira.issue.Issue
import com.atlassian.jira.issue.MutableIssue
import com.atlassian.jira.ComponentManager
import com.atlassian.crowd.embedded.api.User
import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption

import com.atlassian.jira.util.JiraUtils;
import com.atlassian.jira.workflow.WorkflowTransitionUtil;
import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl;

def user = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
if (issue.isSubTask()) 
    def parentIssue = (MutableIssue)issue.getParentObject()
    def currentParentStatus = parentIssue.getStatusId()
    // if the parent has the id of the status TODO (change it with your Jira ID)
    if (currentParentStatus == "10000") 
        WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) JiraUtils.loadComponent(WorkflowTransitionUtilImpl.class);
        // 61  is the Id of the transition from TO DO to In Progress

In order to manage it correctly I suggest adding also the change status from In Progress to TO DO when all subtask moved back to TO DO status.
To achieve this goal add the post function to the subtask transition from In Progress –> TO DO

import java.util.Collection;
import com.atlassian.jira.ComponentManager;
import com.atlassian.jira.config.SubTaskManager;
import com.atlassian.jira.event.issue.AbstractIssueEventListener;
import com.atlassian.jira.event.issue.IssueEvent;
import com.atlassian.jira.issue.Issue;
import com.atlassian.jira.issue.MutableIssue;
import com.atlassian.jira.issue.issuetype.IssueType;
import com.atlassian.jira.util.JiraUtils;
import com.atlassian.jira.workflow.WorkflowTransitionUtil;
import com.atlassian.jira.workflow.WorkflowTransitionUtilImpl;

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.event.type.EventDispatchOption

if (issue.isSubTask()) 
    def parentIssue = (MutableIssue)issue.getParentObject()
    def currentParentStatus = parentIssue.getStatusId()
    // if the parent is in status in progress
    if (currentParentStatus == "3") 
        def areAllToDo = true;
        def subTaskIssues = (Collection<MutableIssue>) parentIssue.getSubTaskObjects();
        // I'll check all subtask's status
        for (MutableIssue subTask : subTaskIssues)
            def subTaskStatusId = subTask.getStatusId();
            // even though this is a post function when you check the item's status that triggers this function it's the old one, so it's not updated
            // I'll check that all issues are in TO DO a part from this issue that will'be in In Progress
            if (subTaskStatusId != "10000" && issue.getId() != subTask.getId())
                areAllToDo = false;
        if (areAllToDo) {
            WorkflowTransitionUtil workflowTransitionUtil = (WorkflowTransitionUtil) 

            // 111 is the transition Id from In progress to TO DO (Stop Progress)
Pubblicato in Agile, Jira | Contrassegnato , , , | Lascia un commento

Conference call meeting sharing desktop or webcam

In my daily work I usually use some meeting conference softwares.

Here a software list I tried:

  • Skype
  • Skype for business
  • webex
  • mikogo
  • (not free)

I don’t wont to describe any of them but I’ll report only some problmes that I came across using them.

Skype works without any problems, the only requirement is that you have to have an account and the partecipants must install the client.

Skype for business. It is the new version of lync and I don’t like it too much. The thing that I hate is that you can have a call or a chat with a skype client but you can’t share the screen. Damn! Both of them are Microsoft program so there’s no reason about this behaviour.
The only way to achive it is sharing a skype appointment using outlook, and the generated link will work downloding a browser plugin.

Webex is a cisco software for conference, it works well but it is for compnay only.

mikogo and require to install a client if you are the caller and sometime I was usiung computers without having administrator perssion so without having a way to install the required software.
A collegue of mine suggested trying this site and I loved it immediately!
You don’t have to register
You don’t have to install anything (a part from browser plugin).
the only thing you’ve got to do is decide the room’s name and share the link to someone else.
It is free and allows to make a call, to use the webcam or to share the desktop. In addition there’s also an integrated chat to share some notes.
You can lock the room when all partecipants have joined, so no one else can join in during your conference.

It halped me many times 🙂

Pubblicato in Uncategorized | Contrassegnato , , , | Lascia un commento

How to manage a Scrum project and QA (Quality Assurance) / test phase with Jira part 2

In my previous article I wrote about the problems I came across using Jira standard project workflow.
In this post I’ll show you in detail how I solved these problems.
Solution Mixing SCRUM and Kanban (it’s not ScrumBan)
In my opinion Kanban is the right choice to show and manage a flow, SCRUM instead, could be good to deal with some status of our workflow.

Dispite of adding the state To Review / To Test / Ready for QA in the dev board, I obtained a good result using a Kanban board for QA users.

First of all I’ve realized two different workflows:

  1. Story (User story, New Feature, Improvement) Task, Bug
  2. SubTask

Here my project SubTask workflow (easy):
In this workflow I configured:

  • TO DO –> In Progress: added a post function using script runner in order to change the status of the parent issue
  • In progress –> TO DO: added a post function using script runner in order to change back the status of the parent issue

Here you can find the script I created for this:

Here is my project Story(User story, New Feature, Improvement) Bug and Task workflow:

As you can see, they are very different and the story workflow has lots of status that I’ll explain when I use it below.
To be honest I use 2 different workflows for Story(User story, New Feature, Improvement) and Bug & Task.
The workflow used with Bug & Task is the same as the story but there are 2 more things:

  • TO DO –> In Progress: I added the validator: Required fields: Remaining Estimate
  • In progress –> To Deploy: I added the resolve input screen in this transition
  • In progress –> To Deploy: I added a post function Remaining Estimate = 0

So I create 3 different workflows where 2 have the same logic a part from the things listed above.
For Epic I used “JIRA Workflow (jira)”

I don’t know if you can understand my idea now, but I hope the next part will clear all your doubts.

SCRUM Dev board:


Before going on with this topic, I suggest looking at Story Point vs Estimated Time and config in Jira

Here the explanation of the only subtask statuses:

  1. To Do:
    Something to do
  2. In Progress
    subtask that are worked by someone
  3. Resolved
    subtask resolved

And that is easy.

Some of them are mapped also for story, bug and task.
Here the explanation of the only Story(User story, New Feature, Improvement) Bug and Task statuses manageable in this board:

  1. To Do:
    Something to do
  2. In Progress
    Something that are worked by someone. In case of story when at least a subtask is in progress.
  3. To Deploy
    The story is completed and committed to GIT (svn, tfs)

In this SCRUM board you can only deal with these statuses.
Noticed that when something is completed by devs doesn’t mean that is ready to be tested because many times they have completed it in their environment but it’s not deployed.
Keep this in mind.

As you can see in the Dev board all status are mapped in the last column. This solve the the "Burn down chart impact (previous post)" because every time an issue is completed, It will "burn" its sorypoint (or time estimate do not use it).
Sprint planning
Before starting the sprint, dev team analyzes the story point of each story and split it in the necessary subtasks. I prefer to estimate each subtask in remaining time, but it’s not necessary. The team can avoid to estimate subtasks if they prefer, the important thing are story points.

Sprint starts
The team starts working the stories moving subtasks from TO DO to In Progress. When they move the first subtask the have to remember to move “in progress” the story as well (I automated it, using Script Runner and I’ll tell you how in next posts).
When all subtasks are completed jira asks to complete the story as well.
The story will be moved to the next available status that is “To Deploy”

This is everything I’ve to do in the scrum board
Easy? yes it is.

Kanban DevOps and QA Board:
This board is thinked for “Operations” that deploy the changes or for only QA team that deploys the changes by theirselves using some deployment tools like jenkins.


  1. To Deploy:
    The story is completed and committed to GIT (svn, tfs)
  2. To Test
    All changes are deployed to an integration/staging environment
  3. In Review
    A QA user is reviewing the story, bug task. Here subtasks are not visible.
  4. Closed
    The story, bug, task respctes UAC
  5. Reopened
    The story, bug, task doesn’t respcte UAC so it’s parked in this status

As soon as a user story, task, bug is done they appear in this Kanban board.
I named this board DevOps and QA because the issues that you can see here are completed by dev but this doesn't mean that a QA team can already chek them.

When all issies are deployed in staging/integration server they are ready to be checked and in order to tell this to you QA team it's necessary that Operation team moves the story from the state To Deploy to To Test. The operation team could automate this writing a script that uses jira web services to move automatically issues. This solve the problem "The QA must work in the same dev environment (previous post) "

Now all user stories are ready to be checked not directly in checking as the default jira baord. A QA member can move the story/task/bug from To Test to In Review and this means that he/her is checking it and this solves “Concurrency QA people (previous post)“.

If the story passes all UACs the QA member move it from In Review to Closed and this means that the story could be deployed in production.

If the story failed the test, QA user have to move the story from In Review to Reopened. But this will not appear to Dev board. In oreder to notify dev team why the story is failed QA user have to create new issues (usually bug or task), link them to the story failed and plan it for the current sprint (this could be the next sprint of the completion of the user story)

Here the detail of a failed story after the creation of some tasks and bugs

Here the detail of the related bug

Now dev team can see tasks or bugs in the dev SCRUM board and using the link dev can understand wich story is referred to.

When dev team completes tasks and bugs, QA can see them appear in the kanban board ready to be deployed.

Using the link inside the user story, It’s easy to understand if all related bugs are complted or not. In case all bugs and tasks are completed QA team can move the story to Close

I wrote a lot, I know!
I hope this solution may help you to manage your software project even if your company is not a pure SCRUM arganization.

Have you found a better solution?
What’s your experience about it?

Pubblicato in Agile, Jira, Management | Contrassegnato , , , | Lascia un commento

How to manage a Scrum project and QA (Quality Assurance) / test phase with Jira part 1

When you start a software project in Jira, usually a basic workflow is generated for you.
I spent lots of time studying Agile philosophy, in particular Scrum and Kanban.
I tried to apply everything I learned to my team and I’ve always had problems applying QA (quality assurance/test) phase.
The “main” book of Scrum “The Art of Doing Twice The Work In Half the Time” written by Jeff Sutherland doesn’t talk about QA phase even thought I think it’s one of the best books I’ve ever read about Scrum.

I look around for some more information, but I didn’t find any good solutions so I did a lot of tests by my self and finally I found my own solution (It’s good for me and my team).
Before talking about my solution I’d explain some other solutions and their pros and cons.

In this post I’m talking about Jira because it’s the software I use to manage my projects.
Jira is a good software with lots of add-ons and a great community, but remember that Jira was born to manage dev issues.
You can understand it by thinking that jira called each item “issue” and looking at the resolution field.

In the version 6.7 Jira generated this workflow for software project

This is, instead, a generated Jira 7.0 Workflow (simplified workflow)

And this is an usual board that use these kinds of workflows:
Image fond online
I think this is the usual situation of most companies…

We can imagine that in a team there are some devs and a QA user and we can imagine:
3 columns for developers:

  1. To Do
  2. In Progress
  3. (Resolved) Code in Review / QA / To Test

3 columns for QA user

  1. (Resolved) Code in Review / QA / To Test
  2. (finish with success) Closed
  3. (finish with fail) Reopened (usually mapped in the same column of TO DO)


  1. Works only if there’s only one QA person
  2. The QA must work in the same dev environment
  3. Burn Down chart impact

1. Concurrency QA people:
In this situation if there are 2 or more QA users it’s impossibile to determine if another QA user is already checking this issue or not. Developers has 2 status to dermine it: TO DO and In Progress.
In this board, instead, QA users have only one status. In order to improve it, it is necessary to add a status To Review / To Test / Ready for QA.

2. The QA must work in the same dev environment:
In this period there are lots of books and resources that talk about DevOps, Continuous Integration (CI), Continuous Deploy (CD) ecc.
I don’t know your situation but not all companies have these systems. Even though there is an automatic CI flow usually the deploy in staging/integration is manual due to you can’t deploy everytime you want.
On account of this It’s necessary that QA checks only deployed iessues and as you can see there’s no way to determine if an issue is deployed in staging/integration or if it is solved only in git or on the dev’s pc.

3. Burn Down chart impact
In pure Scrum QA memembers are part of the team and at the end of the sprint all user stories must be checked by QA (and obviously unit test e integration test) and ready to be deployed as soon as the sprint is closed.
Are you in this situation? Unfortunately, I think it’s very difficult. Even though you’ve automated CI, there are some manual checks (UX) that happens after the end of the sprint. Another situation could be a QA team for multiple projects (1 team cross projects).
For these reasons, I prefer remove the QA from dev board and as soon as a dev complete an issue, they move the issue to the last column so the burn down chart can consider it, and they disappear. Otherwise if the QA team stops some stories by checking it for long time, the story point of these stories are not burned at the end of the sprint. This will cause that a team burns very different story points every sprint, and the storypoint burned in a sprint are not reliable.
The side effect of my solution is that the story points are burned even thought the work done by the team is bad… so it seams that they work a lot… you’re right but next sprint they have to fix all bugs (and I don’t use story point to evaluate QA bug) so the burn down chart will drop.
During the next sprints it will move constantly when the team starts working well; producing a few bugs.

In this article I showed every problem I found working with the default Jira workflow and board.
In the next post I’ll explain what I’ve done to deal with them.

Pubblicato in Agile, Jira, Management, SCRUM | Contrassegnato , , , | Lascia un commento

Story Point vs Estimated Time and how to config Jira to help us

What are story point? what is this shit?! Fibonacci series? naaaaa IO estimate my work in days or hours… I don’t want to bother with this useless stupid system.
How many of you have you thought at least one time this sentence?
I’ve thoughted it for some months when finally I found a great article that allow me to understand why I was wrong!

There are lots of topic that talk about it and I don’t want to write about it in this topic.

Story point is the right metric for our user story estimation.
Could it be the only metric in our scrum project?
No, you can estimate both with story point and time but each of them has a target.

Use storypoint to estimate User story. User story are what our team have to work.

This could be enought to work on a IT project.
If you or your team prefer you could use subtask.

Starting from a user story split it in subtasks that are necessary to realize the user story.

Now your team have two options

  1. Estimate subtasks
  2. Do not estimate subtasks

There is no role, I prefer that subtasks are estimated but it’s not required.
If your team like to estimate it, now the right estimation metric is the time.

To sum up:

  • User Story are estimated in story point (and business point to understand the business priority)
  • subtasks are estimated with time

Starting from this concept, here how to achieve it in jira:

I use story point to evaluate user story, new feature and improvement. I don’t use storypoint to evaluate task, bug and obviously subtask.
In my mind a task is something that I use to ask developers to change but it’s not a bug. Therefore I use task to say something like “the button is not aligned to the table”. Any Change Request is a story not a task, even though the PO change the request IMHO.

Considering that, It means that the effort of doing bugs and tasks are not considered and It’s true. This means also, that probably the story point burned in this sprint will be less and I like this effect bacause this consider if the work done was good or not.

In order to track storypoint and time in the same SCRUM board you have to set this configuration:
Your board –> Config –> Estimation

Pubblicato in Agile, Jira, SCRUM | Contrassegnato , , , , | Lascia un commento