• Transparency:
  
  All project artifacts are available and visible to all members. People can know the status of other works, project status. I saw some people show their importance by hiding source of information, or keep the knowledge of their side. We must prohibit such actions in Agile process. The clear, simple communication plan or good knowledge sharing system will increase the transparency in your project.
• Ethics:

  
  Sometimes, I must deal with the meaning 'What is done?'. Whether people tell the truth when they said they complete their tasks on time (usually, the developer means when they complete 100% functional coding but they do not focus on their implementation quality - I give another blog post about this in future). Give the clear definition of terms you expect all have the same understanding and people must follow the rules. The short iteration requires people report the their statuses, problems exactly daily or bi-daily - They should not hide the facts that could make the bad domino affect to project.

• Team work:

  
  Could we lack team work when we work in a team especially in the environment requires frequent communication among members?

• Freedom:

  

  Think outside the box, the goal is making your project success not 'how to write the use case document and scare customer how professional we are', 'write the complexity architecture to show our high technical competence skills'. Think and do whatever makes your project successfully. Do not fix in one pattern solution to problem, for example 'We only use long pages use case to describe our requirements'.

• Open communication:

  

  You can talk anything in a party, you can show your weakness with your friend but some people can not share the similar things in their project team. They are scared if their project managers know they have the unsolved problems (while their colleague used to have experience and he could solve it in minute), they are scared if they raise their hand and ask a silly question etc. Removing the barrier in communication, listen your colleagues is the key to make inter-communication among members becomes better.

• Maturity:

  

  I believe that fresher could not follow Agile practices successfully without coaching. Some people think that Agile just is the chaotic process, that people just coding and coding (no requirement document, you write code and test) etc. Every one could join Agile process but how about quality? Writing the right unit test is no easy and follow Agile practices such as YAGNI is not simple as what it stated. The responsibilities of Agile developer is harder than the normal one: they must write the test code, they more involve to requirements process/estimation and actively manage their tasks. The works of product owner, tester, BA are different than traditional roles too. What they learn from Agile is different from what they learn before: it is not the definition of milestone, what artifacts must have in some specific integration but the software practices, attitude and flexibility combines with their job competence skills.

The rest of Agile introduction, you can see in my 'Agile introduction' presentation at here .

In our application, we use Spring as IoC container, though set up the Ehcache manager is the easy task but we would like to use it with our Spring beans and exposed it as Osgi service. Spring modules is the good library help us easy in configuration. It provides the consistent abstraction caching to our application, hence we can use our cache facade with other caching libraries such as JBoss cache, JCS, OScache without chaging our application code. You could download the Spring Modules at https://springmodules.dev.java.net/.

Here are the following steps to configure Ehcache in Spring application

Configuring caching via ehcache.xml file

<?xml version="1.0" encoding="UTF-8"?>

<ehcache xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
 xsi:noNamespaceSchemaLocation="ehcache.xsd">

 <!--
 Configure it if you have overflowToDisk or diskPersistent enabled for any cache.
 java.io.tmpdir - Default temp file path
 -->
 <diskStore path="java.io.tmpdir" />

 <!--

    Mandatory Default Cache configuration. These settings will be applied to caches
    created programmtically using CacheManager.add(String cacheName).

    The defaultCache has an implicit name "default" which is a reserved cache name.
    -->
 <defaultCache maxElementsInMemory="10000" eternal="false"
  timeToIdleSeconds="120" timeToLiveSeconds="120" overflowToDisk="true"
  diskSpoolBufferSizeMB="30" maxElementsOnDisk="10000000"
  diskPersistent="false" diskExpiryThreadIntervalSeconds="120"
  memoryStoreEvictionPolicy="LRU" />

 <!--

    Sample cache named sampleCache1
    This cache contains a maximum in memory of 10000 elements, and will expire
    an element if it is idle for more than 5 minutes and lives for more than
    10 minutes.

    If there are more than 10000 elements it will overflow to the
    disk cache, which in this configuration will go to wherever java.io.tmp is
    defined on your system. On a standard Linux system this will be /tmp"

 -->
 <cache name="engroupCache" maxElementsInMemory="10000"
  maxElementsOnDisk="10000000" eternal="false" overflowToDisk="true"
  diskSpoolBufferSizeMB="20" timeToIdleSeconds="300"
  timeToLiveSeconds="600" memoryStoreEvictionPolicy="LFU" />
</ehcache>

Declarating Ehcache in Spring context

<bean id="cacheManager"
 class="org.springframework.cache.ehcache.EhCacheManagerFactoryBean">
 <property name="configLocation">
  <value>classpath:ehcache.xml</value>
 </property>
</bean>
</pre>
<pre lang="xml" xml:space="preserve" xml:lang="xml">
<bean id="cacheProviderFacade"
 class="org.springmodules.cache.provider.ehcache.EhCacheFacade">
 <property name="cacheManager" ref="cacheManager" />
</bean>

Programmatic use

Using ehcache is so simple, a unit test to make the test whether configuration is set up correctly and take the simple put/get could explain all.

@RunWith(EngroupClassRunner.class)
@ContextConfiguration(locations = { "/META-INF/spring/cache-context.xml" })
public class CacheTest {
    @Autowired
    protected CacheProviderFacade cacheProviderFacade;

    @Test
    public void testCacheConfiguration() {
        Assert.assertNotNull(cacheProviderFacade);

        EhCacheCachingModel model = new EhCacheCachingModel();
        model.setCacheName("engroupCache");

        cacheProviderFacade.putInCache("a", model, new Integer(1));
        Integer fromCache = (Integer) cacheProviderFacade.getFromCache("a",
                model);
        Assert.assertEquals(new Integer(1), fromCache);
    }
}

Besides of using ehcache to create the session like variable in our application, we would like to use ehcache to cache SQL statement in iBatis and integrate with Terracotta to complete our distributing caching solution in our future project. I will keep the post on further caching usage in future posts. Keep reading!

• Engroup is the mix project of Java and Flash/Flex with server side is written by Java and front-end is developed by Flex.
• Now, there are many projects:
• • Engroup server has 29 sub-projects (include test projects for Engroup modules and documentation project). The number of projects would be increased in future. Maven is the main tool to build Engroup server projects. In some cases, we combine with Ant via maven-ant tasks to utilize Ant power to support doing tasks that Maven can't.
  • Engroup client has 18 sub-projects. Ant is the main tool to build Engroup client projects by mainly using Flex-Ant task also our custom tasks to generate the code from Engroup server.
• Developers commit code daily.
• Long list of project dependencies: Engroup module projects depend on Engroup core and common modules.
• Back-end services must have unit test for its implementation.
• Database backup must be generated in every build and Engroup installer must be available in every successfully build.

Related build tools:

• Hudson (https://hudson.dev.java.net/): one of the best CI Java build server. Simple to run, simple to use. Have many plug-ins and a clean dashboard to follow the build status.
• Nexus (http://nexus.sonatype.org/): a powerful and robust Maven manager. Nexus is very easy to use and we deploy our Engroup server modules to our nexus server.
• Maven (http://maven.apache.org): an excellent build tool. A must tool for any Java projects.
• Ant (http://ant.apache.org): another excellent Java build tool. A must tool for any Java projects. A combination of Ant and Maven strengthen the power of each tool.

Our standard build process:

1. CI server (Hudson) will get the latest sources from SVN server.
2. Build Engroup projects order depends on project dependencies.
3. Run unit test.
4. Make the reports (thanks for the help of Maven): checkstyle, pmd, junit, cobertura.
5. Deploy Engroup modules to maven repository manager if the build is success.
6. Back up database if all module builds are success.
7. Make the Engroup installer.

Manage projects and build process by CI server (Hudson)

It is fairly easy to create the new build job on Hudson, create 'Create Job' link at Hudson CI server and simply fill necessary information

You can integrate Unit test, checkstyle, cobertura, pmd to project dashboard by selecting them in build settings section.

And you could manage builds and its status on dashboard page, for multiple projects it is better if you customize the list view of modules. For example, in our project we make the customization view for client and server view also view of common artifacts (documentations, installer).

Monitor project health
We can manage the health of project via the following factors:

• Build status: how many failure or success of builds.
• Build warnings: compiler warnings, code warnings (checkstyle, violations) or defined threshold of checking tools (unit test coverage, findbugs)
• Other information: code metrics, duplicate code, source code.
• Project information: development information, license, source repository etc

Go to the Maven site to see project information:

and we can visit some sections to see the detail:

The values of applying CI in our project:

Applying continuous integration in our project give us many advantages:

• The whole process is automated (even backup database task) - no manual task in our build process. No any human mistake causes the build broken, no build check-list is needed any longer.
• Feedback to development status as soon as possible via unit test result and code warnings and some useful metrics.
• Give the project status as you need.
• Managing multiple projects status in one place.
• Developer could get the latest other works as soon as possible (thanks for nexus - open source maven repository).

Applying CI in your project should be the good option for your project as we get in our projects. Just takes some hours to make all things are run properly but the benefits you have is far greater than the effort you spent. Let's try, see and enjoy!

Instead of writing tasks report at the end of week (this way place project member in passive way, they only record what they are assigned to do by PM), each project member spend 15 minutes/day (75 minutes/week) to answer three questions "What have you done? What do you plan to do? What impediments do you have?". The Scrum Master only set the goals to be completed in week and project members are freely to plan their tasks to complete their goals. This cause project member active to think what they do, and they manage their tasks in order complete project's goals not wait the instruction from PM. Before applying Scrum practice, we receive many complaints like "Members are not active in their jobs! They do not raise problems to us etc", after applying the Scrum daily meeting we can update the project status every day! And people active to solve problems. If you have not applied daily standup meeting before, you should try it soon!

There are some tips to make the daily standup meeting more effectively:

· Do not try to solve problems! Only related people seek the solutions later not in daily standup meeting.

· Limit the number of members less than 7 members and they only focus into 3 main questions, no more and no less.

· Scrum master deliver the project information briefly (news, project change etc). Any message not belong the daily meeting scope should leave for weekly meeting or another group meeting.

· Daily meeting should proceed at the beginning of day, not middle or very late. Do not let the short meeting impact to current employee's works

· Project members should report descriptively about their task. No use ambiguous statements like 'Yesterday, I fix some defects or do some bugs'. Report task of one day do not take a lot of time of developer. With long time tasks, it should be divided into smaller tasks (1-3 days) and have output to make all developers can understand the work done by reporters

- The different speed of working among associates. The clever can interfere much the thinking of other and developers are not peer but teacher and student relationship. With teacher-student relationship, it takes time for senior to work the same workspace with less mature one and we have other types of training instead of pair programming.

- Pair programming should not applied in 'political' or unfriendly environment. People tends to protect themselves and try not show their weakness to others.

- Some people just like to work lonely. They do not like any involve during they code until their works are finished.

- We do not need two guys do for simple works.

- Sometimes people need relax, other member will force them work while they are tire. There are some guys can work without relax within 4 hours but others need, the different focus level in work can cause people tire and protect against pair programming.

With above reasons, I do not see pair programming can be applied to many teams especially the big team because they are many tyles of working, any fail in one pair can impact to others. However, without any close cooperation among developers than current, it also cause issue about quality and knowledge management, the result is clear: code is not reviewed well (code review session is not effective because people only select random source file for code review in meeting), people can not share knowledge of coding and works etc. The simple thing we can improve our works to full code review to all source codes, two people understand the same code base is performing the peer review regularly. Instead dividing into pairs for coding, we let pairs do review only, one will code and other will review their works at the end of day. Pair review should be performed every day because when some pair leave works not reviewed daily basics, they tend to select random files for review only when managers request and the effectiveness is not much. Review other works in daily basic will take much time at the beginning, but it takes more speed in future when people is aware with other's source code, business domain. We also sure each line of source code are 'done' by pair (one code and one do inspection), if there is any conflicts in pair, the technical lead will join to solve the issue. One drawback of pair review with pair programming is the response time for fixing defects, pair programming do faster but I believe the benefits of pair review is worth for pair and it overcomes the limitations of pair programming to make it can be applied more wider area.

First, we go to the common related technical problems

1. Lack high technical skilled resources

In the resource market, there are just rare high technical skilled resources who has experience of developing architecture, design for various kinds of project and technologies. In Software Company, the ratio of technical architectures resource also is less than the needs of organization.

2. Re-discovering and Re-inventing common solution domain

Solution domain is discovered or invented in other product is not distributed to related products in a product line. Organization takes a lot effort for re-create solution for problem that is solved before, the solution can catch the traps of previous ones or the quality is not good enough.

3. Monolithic Construction - No reusable components

Not only solution domain is not kept in all products in product line but reusable components across products, product lines are not defined. In addition, organization does not have strategy of defining the re-use level of component, what is reused and how it is re-used. The rigid architecture is also the reason cause all components in one product are heavily tight, that cause its components can not be used separately and it is hard to bring one component to other products except bring many related components (but they are not related business domain of new product) and perform tuning code for new products.

4. Inefficient of R&D activities

Nowadays, there are many methodologies, toolkits, frameworks that help development members can increase their productivity and organization can deliver the better quality product with competitive cost. Normally, the cost for R&D occupies 2-3% operation cost of organization and it is not much cost to have the outstanding result especially in small-medium size company. In any company, focusing on some specific technologies and tools is the wise approach to strengthen organization knowledge instead of assigning limited number of resources to research many tools, frameworks

Long time ago, software organizations realize that some components can be re-used across projects and they define the process that promote re-usability of software artifacts, they are documentation, architecture, module, components or API library. However, lacking the good process also the criteria, guidelines, strategy for creating reusable artifacts take many companies effort without the valuable result. By categorizing projects into separated product lines that helps software company can limit the number of product lines they are developing also define the better strategy for reuse. The reusability is not limited in API library, component etc but the group of products that share the similar business domain or architecture, technology. Product lines is the rather new terminology and there are only few resources about it, recently Software Factories term are raised many times and it has different meaning to Product Line though it is derived from Product Line. However both of them promote the reusability of software artifacts.

Product lines introduction

According to [9], Software product lines represent a significant departure from software reuse schemes in which attempts are made to make assets as general as possible without the context provided by an architecture and a scope definition, and from opportunistic reuse schemes in which low-payoff assets are scavenged adhoc from a reuse repository.

Product lines pay off because the investment in the core assets is allocated across the entire family of products. The core assets provide a production capability that allows rapid construction of high-quality products.

Build a product line is a complicated task. In general, it takes a long time for building a set of related products especially it is true for outsource company that usually not control what products they will receive in future. Though maintain the business modeling across the products in one product line is difficult but the task that maintain the architecture also the reusable components in one product line is simpler. One template architecture is applied for one product line that is distinguished to others by architecture, technology also the domain knowledge. One template architecture consists:

Architecture design:

• Software patterns: Integration patterns, design patterns, infrastructure patterns.
• Object Oriented Principles: Open-Closed principles, Liskov principles, etc

Domain knowledge(s): Healthcare, eLearning, Telecom, etc

Technology and Platforms:

• Operating system: Windows, Linux, …
• Platform: Java, .NET, etc and its version platform.

Re-usable components:

• Common API: validation, logging, caching etc
• Domain API: HL7 (Healthcare), Barcode, EDI etc

Development workspace:

• Tools: are used to build product base on template architecture. That includes development tool, build tool and deploy tool.
• Guidelines: document guides people how to build product base on template architecture. It includes using common patterns, object oriented principles also usage of common and domain API. In addition, it also guides the usage of tools or practices of implementing on specific problem domain.
• Samples: it guides development in practice via samples for basic problem that can serve to solve harder domain problem.

There are two things need to be considered, they are domain knowledge (that belong to business area) and technical artifacts like architecture, components (that belongs to technical area). One architecture that fit with one domain also it depends on deployment model. Two template architectures can reuse the same artifacts, such as two healthcare applications on window and web environment can share the components like HL7, EDI etc but they can have different software patterns for separated deployment model.

Benefits of template architecture

1. Increase productivity

The easiest thing we can see that productivity is increased, the cost is decreased. Development team members do not need to create or implementation from scratch, but they develop base on an existing TA that have guidelines, best practices also expert can support them use the TA.

2. Predictable result, higher quality

Due to TA is built by experienced technical geeks, also it is contributed by many real practices from previous projects, the feasible of solution or architecture are proven that make any solution base on TA is predictable and it has good quality

3. Re-use of skills, resources

Lack of high technical resources also they are many frameworks, toolkits, etc that has the same functionalities cause R&D is difficult to define what area they should focus in. By fixing with one solution for one kind of problem that cause organization gather all efforts for this problem instead of dispersing its effort. Members also learn the best tools, best practices of solution and have deep knowledge on it instead that they know many functional areas but only introduction level.

4. Competitive advantage

It is obvious that if one organization can provide the good solution to client, deliver the high quality product and the cost is competitive, that company has competitive advantage compare with its opponent.

5. Resource allocation

By simple usage of Template Architecture also it contains guidelines, practices. That free some experienced technical geeks outside project development. Team members can develop application base on Template Architecture, which are very easier to detect any violations to architecture and implementation. The experienced technical geeks can be assigned to more important tasks such as mentor technical activities, building other template architecture.

Reference

[1], Nguyen Phuc Hai – Template projects in Software Development, http://www.haiphucnguyen.net/blog/?p=36

[2], Nguyen Phuc Hai – MVC Pattern: Controller is too big, http://www.haiphucnguyen.net/blog/?p=42

[3], Software Factories – http://www.softwarefactories.com/

[4], Edward Bakker – Factories 201, http://www.edwardbakker.nl/

[5], Spring Framework, http://www.springframework.org

[6], Spring Modules, https://springmodules.dev.java.net/

[7], Enterprise Library 3.0 – April 2007, Documentation

[8], Jezz Santos - Factories’ ABC, http://blogs.msdn.com/jezzsa/archive/2006/08/09/sfxjargon.aspx

[9], Software Engineering Institute – Software Product Lines, http://www.sei.cmu.edu/productlines/

[10], Gunther Lenz and Christoph Wienands - Practical Software Factories in .NET

[11], Jack Greenfield, Keith Short et al – Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools

1. Don’t resist. While your gut reaction to change is often refusal, such a response is not productive. Change is inevitable, and you must learn to accept it. The quicker you do, the smoother your transition.
2. Find the positive. Even the most difficult changes can produce positive results. Don’t waste time dwelling on what you don't like. Focus instead on the potential benefits and new opportunities the changes may bring, and your spirits will remain lighter throughout the transition.
3. Create a list. You'll feel much better about change when you're able to manage its details and results. Make a list of what needs to be done to implement the change. The more prepared you are, the less change will overwhelm you.
4. Familiarize quickly. Jump headfirst into change, whether it’s new ways of doing things, new offices, or new teams. Take time up front to learn a new program, take a tour of a new office facility, or introduce yourself to a new coworker. The more quickly you are acclimated to new things, the more quickly they will become familiar to you.
5. Consider others. Change rarely affects one person; in most cases it affects many people at once. Change experienced as a group can become either a supportive, unifying experience or a negative, frustrating one. Consider what kind of group you want to be a part of, and then seek to make it so through your words and actions.
6. Focus on one change at a time. While we can learn to accept and manage change, piling numerous changes up all at once can become too overwhelming, even for the most flexible of us. If there are many changes going on in your work life, this is probably not the best time to also start those home renovations. Managing change in one area of your life is easier when you have other areas that remain familiar and comforting.
7. Exercise patience with yourself. When things change significantly, accept that you will not be able to master them all right away. If you're dealing with updated computer systems, a shakeup in business operations, or any other major business change, things will take time. Give yourself a break, and don’t add to your stress by trying to become a whiz at everything overnight.
8. Ask productive questions. Ask yourself questions that will make a positive difference, such as, “How can I help facilitate the transition?” or “How will I need to adjust my daily schedule to accommodate this new process?” Avoid asking “whys,” and instead learn to move forward by asking questions that will help you become comfortable with the changes.
9. Take control. Change is stressful because it threatens a person’s sense of control. Don’t allow a powerless feeling to overwhelm you; face new challenges head-on. Focus on how you can make it work for you. You will feel empowered by your renewed sense of control when you stop allowing change to overcome you, and instead overcome change through hard work and steady determination.
10. Don’t get too comfortable. While it's important to familiarize and adjust to change, it's fruitless to get so comfortable that you believe things will not change again. Adjust, but do so with the knowledge that nothing lasts forever, and this too may give way to more change in the future.

Talking by my voice about managing change in one organization, we must agree that let people accept the change or any innovative program can take period time to implement successfully but it is the must for organization to grow. Time to complete the long period program can be long (2-3 years or more), but each milestone achievement can be verified in 3-6 months. There are two approach of changing current working process:

• Improving current process: organization identify its problems such as low productivity, bad quality, high cost of operations etc. The executive team want to have an improvement plan to change this circumstance. Some expert teams are established to identify all problems and propose solutions. After that the solution is implemented to organization. Some process such as TQM, Six sigma etc support to this approach.
• Reengineering organization: re-engineering organization takes sorter time than improving current process, the failure rate is higher but the ROI achievement may be much higher. This approach requires the organization will change even its basic operations or its business areas. The change is required because it relates to survival of company, or the change require when company wants to move from 'red ocean' to 'blue ocean' - see book "Blue Ocean Strategy: How to Create Uncontested Market Space and Make Competition Irrelevant" at here http://www.amazon.com/Blue-Ocean-Strategy-Uncontested-Competition/dp/1591396190)

Careless the approach of changing organizational behavior, two more things besides above 10 tips are the support of associates (especially from BOD) and eight key factors of any Quality Improvement Program(see http://software.isixsigma.com/library/content/c021230a.asp)

Why it is a problem when we have common process for all projects in company? The reason is simple: each project has specific characteristics, and they require you must custom our process that adjust its context. However, three problems are raised:

• If company find that the current process can not cover some mistakes in some projects, they will add more rules to process (that means add more works to project members) to prevent this problem in other projects. We can understand this fact as they made the process more 'perfect'. However, such additional rules may not help other projects to fix its problem and project team members do not care its rules but it takes effort of considering, in some cases it takes time for them to do just because the rules define. The consequence of adding more rules is obvious, project effort is increased and company process becomes bigger and bigger. Some projects use a small part of this process, others use another part.
• It takes more time to maintain and study: the more bigger of process, the more time to learn . In addition, it also takes process engineer takes more effort of maintain the consistent of process. Any changes in process take a lot of effort to correct other places.
• Project team members apply process incorrectly: of course, all rules of one process can not apply all to projects. Company allows project can customize process that meet the project goals. However, if project has the right to customize company is not sure that what they think rules are un-needed is correct? Some cases, they remove some rules is the key factors to project success or when they choose another approach but no support from company. I give you a detail example: if there are two projects, one has 40 and other has 10 associates. The first project, client expect you have the formal communication with formal requirements and follow the requirement workflow strictly. The second one, client also require how you develop the application as soon as possible with high quality. With the first project, we can choose to apply the Business Modelling and use cases is the main artifact of managing requirements, it is supposed the company support this approach via templates, guidelines etc. But the second one, project should choose more agile approach of managing requirements such as writing user stories. If the company does not support, team must do by themselves. Of course, user stories may not added to process because in some meanings, user stories and use cases serve for the same purpose.

In manafactoring company, it is clear that we can have one workflow that serve for one product line. Software should not be considered as one product line but it should be divided into many groups that have the similar characteristic. That help company can control the software development process apply for each project strictly, project receive more guidelines for company and the effort to maintain will reduce. Just link to programming language: having a big process for all project is similar with you writing the program using procedure language, if we have one process for each kind of projects it is similar you use OO for programming. Of course, software development process also have inheritance characteristic . Here is the example:

Core Software Process: (the must for all projects in company)

- Requirements, Analysis and Design, Implementation (Code review check list), Testing (Unit test ...)

RUP Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (Business Modelling, Use cases, ...), Analysis and Design (template document...), ...

Scrum Software Process: Core Software Process (custom for specific kinds of projects)

- Requirements (User stories ...), Analysis and Design (template document...), ...stand-up meeting ...

The kind of project does not mean about the team size but we can categorize the project base on client's expectation (does they need the formal requirements, test cases ..., high quality product), project's context (lack of client support, domain knowledge is complicated, maintenance on legacy application) etc

Technorati : Project Management Software Development Process