Xinh chao! Toi la @kakeyang. Toi thich binh my va my xao va xoi!

I wrote that we’ll be unsuccessful for offshore development if you do like these in the previous article. In this article, I list up the concrete method in order to operate offshore development project successfully in SEPTENI TECHNOLOGY on the basis of it.

Offshore development often makes us Japanese imagine that we can’t improve quality of software. So I focus on the methods to improve quality in this article.
We have not completed them all and are advancing both team building and methodology but I feel they can be getting to effect to quality.

The most important points are to promote early feedback and to improve quality of unit test.

Small development and small deployment with Scrum

* modified image

The most unsuccessful condition in offshore development is recognition difference due to communication loss, that is the condition that ‘things that we didn’t expected at all are developed’. In order not to make these situation, we have to review all of outputs in detail but recognition difference can occur. We may regret in testing phase that ‘oh… they can interpret like this…’.

So this is also important that we have to build team structure that we can detect earlier and developers can modify them earlier in precondition that recognition difference can occur. We’re advancing Scrum like these below.

• 2 weeks for 1 sprint.
• We take Sprint planning meeting at the beginning of sprint and list up all of tasks for this sprint for about 3 ho0urs and make them all to be tickets. Each ticket should be divided whose estimated volume is below 8 hours.
• We take Review meeting at the end of sprint and suggest concrete action plan that we should do at the next sprint.
• All team can share the progress of each task that we have to do as a team in daily scrum meeting.
• Daily scrum meeting is taken in the evening too in order that all member declare they could really complete all tasks this day.

Build SQA team

From my view point as a Japanese, quality of unit test by Vietnamese engineer is low.
I imagine that they have never taken education of how to unit test.

Sometimes we can’t joined test due to low quality at the beginning of joined test phase.

And I feel that Vietnamese engineers totally don’t suit for creation and execution of test cases as my experiences.
From these reasons above, it’s very important to build SQA team in order to design and create test cases during detailed design and coding by developers in parallel and to compensate quality by volume of testing. Most of SQAs are women in Vietnam but they can contribute improving quality because they usually very diligent and serious.

Adopt TDD

As I wrote many times, the biggest problem is low quality of unit test. So we define that we have to output test script surely with adopting TDD coding.

But the reason why I adopt TDD is not only that. Another big reason is to prevent degrading.

Degrading can occur very frequently because local engineer have to modify source code that foreign people (means Japanese) wrote in offshore development. And I think it’s sometimes mystery for local engineer and they often can’t catch all of affects to existing function completely when they enhance functions and that causes degrading very often.

Degrading is one of big reason to decrease quality.

That’s why I adopt TDD in order to build structure that we can detect whether or not modification of source code affect to existing function with executing all of test scripts when push by git with Jenkins in precondition that we output test script as a set of main procedure.

CI with Mr. Jenkins

I would like to do this the most.

We can realize that we detect degrading with build script and make situation to test earlier by excellent SQA if we adopt Continuous Integration. So I would like to do it soon.
I plan to entrust checking source code quality with static check of source code in parallel.

Now we are growing up CI environment from now on. So I look forward to make it.

This presentation below is the one in seminar inside our company to teach ‘what is Continuous Integration’. This is very simple description about it but I think it suits for teams that are considering of introduction of CI.

I try to make it with cool design in vain. I appreciate for these links below because I referred for presentation design (most of them are written in Japanese).

* total
http://zachholman.com/posts/slide-design-for-developers/
http://kotas.hatenablog.jp/entry/2012/11/22/000046
http://blog.riywo.com/2012/10/02/011200

* color
http://www.colourlovers.com/

* font
http://www.yanone.de/typedesign/kaffeesatz/

Our excellent Vietnamese engineers plan to write articles about more detail of Jenkins and Continuous Integration, I expect.
This article in English can be referred this SEPTENI engineer’s blog.