Pair programming – ideal only theoretically

Fornádeľ Michal

Abstract. Pair programming as a part of extreme programming is based on active cooperation of two programmers working on the same task side by side. Regarding the increase of efficiency and the quality, it is absolutely significant to identify mutual activities and refuse to program in pair all the time. Different character qualities, abilities of programmers and the type of project are relevant for considering the fact if pair programming is suitable technique for usage. From the theoretical point of view, advantages of pair programming are very beneficial for both members of development team and managers who reduce financial resources and qualitatively increase the level of project. Unfortunately, the practical experiences have shown that many programmers are a bit skeptical because of difficulty according to the time synchronization of pair, mutual misunderstanding, personal discomfort, feeling of endless control and loss of concentration. Pair programming is suitable for activities demanding further investigation and different conceptual views. Other activities from the programmer’s point of view could bring some disadvantages.

Hitka Matúš

Abstract. Measurement in software project is the best way to identify project state during its realization. Software metrics are used for measurement in software projects. However, the real value of these metrics may be affected by the psychical effort of measurement on the people. This may leads to the state, when the development of product is oriented to reach better measurement result rather than to achieve a goal. In this paper I discuss suitability and usability of three frequently used software metrics: lines of code (LOC), function points and defect density. All of this metrics have their Pros and Cons. There is no metric that covers all phases of the software development. This is why it is necessary to combine them.

Control the future of Scrum projects

Hlaváč Marek

Abstract. The future of software projects is important, but often forgotten and underestimated topic. From the perspective of agile development in the context of Scrum projects it`s a significant and indispensable part which is pointed out in each development phase. A successful future is assured through project monitoring and controlling. The aim of project monitoring and controlling is early identification of risks and their early removal by using appropriate techniques and metrics. This is the reason why there are so many project failures. For Scrum processes this opens up new possibilities in the selection of specific techniques for different situations. The point is to record essential values that allow us to monitor the status and progress of Scrum projects and their dynamic nature. From this point of view we can define the questions with competent answers which are a prerequisite for future control of Scrum projects. What are the ways of monitoring Scrum projects? How to detect potential risks? Why you should be careful in project monitoring? Where lies the power of project controlling?

Small team, large team, international team - does it have influence on risk management?

Kubis Viliam

Abstract. Selecting the right method of risk management is a crucial decision that needs to be made at the beginning of a project. Incorrect risk management method choice can lead to complete failure of risk management process, which will significantly endanger the succes of the whole project - it can lead to a complete haltdown and failure of the whole product. Analyzing and thinking about a particular risk management methodology to choose is one of the toughest decisions a project manager has to make. According to what criteria can a project manager choose the right risk management method? Are all presented methods pricipally equal and usable for each and every project? Is team size and geographical structure significant and important in the decision making process? We strive to answer these and many other questions, or at least provide hints which will lead to making the correct decision - and in turn success of the whole project.

How to successfully communicate in virtual team

Pavlech Lukáš

Abstract. Communication in software development as well as in other disciplines is very important factor. In the traditional team communication is quite simple. The entire development team is located in one building. Thanks to that, any problem that appears team members can resolve quickly and effectively. On the other side, project in virtual team has more communication problems because of different geographical location and often different working hours of the team members. Proper selection of communication tools with respect to team composition and experiences of team members in one of the success factors in virtual team project. Only selection of the communications tools does not guarantee to project manager success of virtual team. Therefore, in this paper I discuss the selection process and proper use of communication tools.

Code ownership and its reasonable limits

Petráš Daniel

Abstract. For each development team, there must be some rules to follow. There are many such rules and the management is to choose those, which will make work in a team more efficient. Such rules are called organizational patterns. One of these patterns is the code ownership pattern. I address when it is appropriate to use this pattern and what are its advantages / disadvantages and risks associated with it. I summarize what this organizational pattern includes (it's not just about who owns the code). I Show why unyielding compliance with code ownership is not suitable and why code stewardship is in most cases more appropriate and flexible model. Finally, the essay also mentions other patterns and anti patterns that the subject of code ownership is related to.

Everyone makes mistakes…that’s what testers are for

Pomothy Adam

Abstract. Nowadays, testers are usually considered to be temporary one-shot employees. They are given only test scripts and rules, how to report found errors and they are supposed to do their jobs. However, testers are equivalent to a development team. They have the same goal – to deliver a high quality product to a customer. The communication is crucial for these two teams. However, if new testers are hired for every project, they have no relationship to developers and they are also in brand new environment. As a result, their communication is too formal and inefficient. That is the reason, why it is important to have a static team of testers as it is in case of developers. Good relationships or friendships result in much better cooperation. To achieve as effective communication as possible, it is also important to choose team leaders of both teams (it is common in case of developers, but not in case of testers). Team leaders coordinate other members of team, they are aware of current tasks and they communicate with external world in the name of whole team.

Creating Team Synergy with Commitments

Škvarenina Pavol

Abstract. In this essay I address the problem of creating an iteration plan within the agile methodologies. I briefly explain the two base iteration planning methods, which are velocity-driven iteration planning and commitment-driven iteration planning. I discuss the suitability of both methods with confrontation with relevant experience and knowledge of other authors. From the confrontation I suggest to use the commitment-driven iteration planning method as this method is more suitable in the context of working with agile methodologies. Commitment is a bald statement and with it the development team gives a promise to stakeholders that they will finish the iteration with completing the planned goal. With this the development team creates a great feeling of motivation, self-trust and trust with the whole team, which creates, by my opinion, a synergy effect throughout the whole team.

Quality documentation? How to do it?

Zachar Radoslav

Abstract. Documentation is text necessary belong to every software product. Each developer or development team has to create their own documentation. Content of the documentation always strongly depends on the size and complexity of the product. It’s lot of time spending on creating documentation guarantees the quality of software? Creating high-quality documentation is not as easy as it may seem. It is very important to know how to reasonably divide the entire development time between the creation of documentation and writing source code.