Here are the new user features of engroup 1.5.1, the detail changes can be read at http://esofthead.com/node/51.

1. Project Management module:

• Helps enterprise manage their works easily with hierarchy tasks, deadlines.
• Collaborates project members, store project information with messages and their comments, attachments.
• Manages project resources and statuses such as project members, risks and problems.
• Provides automotive scheduling base on various variables start date, end date, predecessor tasks.
• Integrations with Microsoft Project: import/export data to/from MS Project format.

2. Connection module: is extracted from previous Dashboard module

• Private messages.
• Members List.

3 User Profile module: is extracted from previous Dashboard module

• Uploads user picture to profile section.
• Crop picture to profile picture.
• Displays profile picture.

We will write the usage of engroup modules such as document management, project management in future posts. Stay tuned.

1. Do you feel angry because you think he did bad job without care quality or he is a junior developer who do not have experience to do the right thing at the first time?

2. You are agree with your developer but you are afraid that customer think your team produce a bad result and take time for correction that make project cost is increased?

With many years experience of project management in various team sizes, and senior project manager manage a big account over 100 members with my direct subordinates are project managers, I must admit that such situation occurs sometimesand it makes developers are afraid to tell their manager that they need time to make their code better.

Note that my 'bad code' definition is not source code has low quality such as having a lot defects or do not following coding standards but a 'bad code' means you can write a better code to solve project problems, optimize your code, gain better performance or increase re-usability. I have worked with many talent developers who handle such tasks as extra tasks not belong in project schedule and do it in their own time (though it is not a good for his personal time), but most of time all project members are afraid to modifying existing code base while project manager do not approve. Here are the result I see: the bad code is not optimized, it is modified base on new requirements from customer and it becomes terrible code with low quality, many defects. The cycle is repeated, developer are afraid to make it better, it become worse and so on. Project will have many technical debts and when the project size is grown bigger, team productivity will decrease continuously. Project quality is complained by customer or even they cancel project, otherwise project members must work overtime to fix defects with low source code quality. Most of cases, customer are not satisfied project performance and/or project members are exhausted, company lost profit.

It is normal in project management if we leave 2-3 free days after each iteration for team spending time to look what they did in the past, a knowledge management system is a tool for members to share their knowledge and works and project technical lead review solutions right away or weekly basic to improve code quality better if you do not want to spend much effort fixing later. Managing and developing software projects have many pressure: quality, deadline, customer feedbacks etc, there are not all software solutions are reviewed by all team members to give feedbacks about their advantages and disadvantages, there are some common API is developed by one developer and others try to use without giving any comments or they think they have no time to tune that API better. If you let such situation happens, your project has a red alarm!

• 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 .

• 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!

In the project has both lazy developers and non-lazy developers, project managers usually do the wrong thing that assigns the lazy developers more jobs to share workload with the non-lazy ones, that causes all people tend to become the non-lazy ones. In this case, project manager should motivate people become to the lazy developers, it is an art!

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)