SVN repository - Google Code

weaverchurchSoftware and s/w Development

Aug 15, 2012 (4 years and 10 months ago)


What is working well

Pizza night

The whole team goes out for dinner. Pizza night in the team's context is dinner. This activity was
initially done when one team member was hungry before a specific meeting. That team member
suggested to have dinner togeth
er and called in everyone to come early. During dinner, the team
interacted like old friends and that gave the whole team a bond.

Meeting minutes

The meeting minutes that the team did was not regular meeting minutes. Usually, meeting minutes
are done at t
he end of each meeting, what the team did was doing a minute for the meeting only for
significant decisions that was made during the meeting. This is to inform of the absent team member
of the decisions made during the meeting. This way, the team member do
es not have spend time
reading through minor decisions that does not really need to be reviewed

NetBeans IDE

NetBeans IDE was chosen for the team's unified IDE. It worked well due to the fact that all a team
member needed to do was to just import the fold
er that the project that was in. Once imported,

the project properties will be adjusted to the team member's work station.

Coding standard & Naming convention

The team decided the coding standard when NetBeans IDE was decided to be the unified IDE. Th
is because NetBeans IDE has a function for the users to format the code in a certain way. The team
has decided to use the default formatting of NetBeans IDE. Naming convention worked well only up
to a certain point. Package, class and most of the variab
le naming had a specific convention.
Variables were named from lowercase then uppercase for the first letter of the second word. For
example, assignment submission variable would be assignmentSubmission instead of
AssignmentSubmission. However, in class's
get and set methods, some of the variables that were
used were different. For example, to set an id of a certain class, some used,
some used

and some

, but if

was used, the whole class would use that particular convention.

r programming

Pair programming was the second iteration for the project. Pair programming worked well for the
team due to a few factors,


Team bonding

there will be a bonding between the pair once they start on their task, improving
their relationship.


mmon and more in depth understanding of the system

the pair will gain different
perspective depending on what their partner knows.

SVN repository

The SVN repository is the place that the SVN client uploads all the team's source codes and
as well as any other tools or components needed for the project. SVN repository
worked well for the team due to the fact that it was a
“one click”

solution for downloading and
uploading of project files and documentation. One will just need to “
check out”

the repository with
one or a few clicks at most and all the project files and documentation that is needed will be
downloaded and readily available.

Automated testing

The use of JUnit allowed the team to run all the previous test cases that was developed
with one
click of a button which was handy especially at the end of an iteration.


Spikes was a way to introduce to the team new tools and terminology. Spikes was first done on the
first iteration on what was to be used and the way to use them, incl
uding the SVN, wiki, and many
more. Those spikes was successful in terms of conveying the information that was needed to know to
the other party. That success lead to the team's decisions to use spikes for any other new tools or
terminology that was being
introduced while developing the system.

What is not working well

Task responsibility swapping

During the second iteration, which is the pair programming iteration, the team decided to swap
responsibility to ensure that one team member is familiar with m
ore than one layer. Essentially, the
team's UI layer developer and the business layer and data access layer developer swapped roles. The
team found out that swapping roles was a bad idea. Not only that the development of the system
took longer, the system
was modified in such a way that the original person developing it did not
know what the person that took over did.


Maven was initially to be used in the project, due to the fact that one team member is familiar with
the tool and has demonstrated on
how it works. The spikes for the tool was also nearly complete. It
was then that the team had a sudden discussion that decided that it is best to use a tool that everyone
was familiar with, even a little. It came to a conclusion that ANT will be used, sinc
e majority of the
team members already know how it works as opposed to Maven

SVN repository

The SVN repository was not working well for the team because of several reasons :


there were properties file on each separate team members' work station. This wa
s uploaded to
the repository whenever the team commits the project and when another team member checks
out from the repository, the previous team member's properties file will be overwritten and the
team member will have to reconfigure the whole project. T
he reconfiguration might take only a
little while, but if this continues on for every team member, a vast amount of time is lost which
could be used elsewhere, such as testing or developing code.


Risk list

Team member unavailability

unavailability o
f team members are usually more often than not something unpredictable. This will
then lead to more work to be done by the other team members. While this event is unpredictable, it
is usually does not bring an impact powerful enough to stop the iteration,
however, it will some
times influence on how the team does things. For example, the team member that was responsible
for the UI layer suddenly has an important matter to attend to, the other team members, who are not
so efficient in implementing the UI lay
er will not be able to comprehend the style of the missing
team member.

SVN conflicts

When using SVN, there is always a chance that files will have conflict within itself. When
this happens, the conflict itself may take a short time to get fixed but it ma
y also take a long
time to fix. This is especially true if the conflicted file is long.

Different understanding of the system

There is a high chance of this happening in each iteration. This is because of the perspective and
background of each team member.

While most of the time after some discussion, the team will have
a similar perspective of the system, some times, the mental picture inside each team member's head
is different, even after discussion, more so if language is an issue.

Requirement changes

in an iteration

For the requirement to change within an iteration may or may not impact the flow of the project. It
depends on the change that was introduced. If the requirement change's impact on the system is
small, it would not be so bad but no one wou
ld know how much impact a change would bring in the
middle of an iteration, no matter how small the change is.