Distributed Pair Programming: In distributed pair programming, two person that are developing the code are at different geographical location, and follows the same principal as pair programming where they share single machine instance to develop the software. According to [1], there are two person involved one is called driver and another person is called navigator. Driver has control over computer and does the coding. Another person called navigator checks the code, checks the logic of the code, give advice to driver and constantly checks whether team is going in correct direction or not. Typically, driver and navigator interchange their role at interval of 20 minutes [2].
There are several ways distributed or remote pair programming can be performed: [1]
- Use of collaborative tool called ‘chat room’.
- Shared software artifacts.
- Use of hardware and graphics for collaborations.
According to Baheti et al. in [1] ‘chat rooms’ are most common and widely used. Here two person involved in remote pair programming use any of the available chat services such as yahoo, MSN or AOL.
Authors in [1] also mention that shared software artifacts can be used to overcome the disadvantages of ‘chat rooms’ such as ambiguity in expressing some complex process via chat and difficulty faced by one of the parties to give explanations and delays incurred by that. There are various software artifacts that can be used in remote pair programming environment. According to Schenk et al. in [3], VNC, Adobe Connect, Skype, Microsoft NetMeeting can be used in remote programming environment. Other tools can be distributed IDEs which allow both users to save file in their local memory and all the changes in the files are synced accordingly. Both Users can share their cursors and their view such as scrolling, typing etc. According to [3], Sangam [4], Xpairtise [5] are strict remote pair programming environment. In here, only one person is allowed to code and the views are synchronized between two partners.
In Use of hardware and graphics for collaborations authors in [1] mention that they are generally used for data visualization purposes rather than software development purposes. Here the purpose is to create a collaborative theatre to simultaneously display the content up to 3 theatre screens and to visualize high dimensional scientific data.
Jazz Sangam: A tool that supports remote pair programming is Jazz Sangam [6], Jazz is a software development tool which supports collaboration and is developed by IBM’. It has features such as source control, instant messaging, team process and defect management. Jazz Sangam is extension of Sanagam [4], a remote pair programming plug in for Eclipse IDE. Jazz uses client server architecture with specific focus on different collaborative technologies. The architecture of the jazz is highly extensible because it uses open web standards. This tool has three main features: Jazz source control, Work Items and Chat. It implements its own version control system such as subversion. The developers can manage their local changes and can see the changes made by their team-mate in real time. Jazz Sangam has its own bug tracking system call ‘Work Items’ which is similar to BugZilla. Jazz Sangam has a ‘Chat View’ and can be configured with Google Talk, OpenFire server etc. These features of it can enhance the experience of remote pair programming with additional features.
The pitfall of remote pair programming according to [7] would be, it is challenging to develop a cross workspace infrastructure that is isomorphic. However, there are several tools developed that not exactly but mimic the isomorphic behavior. However according to [8], inability of partners to express the logic verbally and this issue can increase the required amount of time to develop the software. However, there are some tools that supports video and audio integration but they lead to higher consumption of memory bandwidth. Other pitfall could be inability to express the complex conceptual logic without any whiteboard. The potential solution could be to integrate virtual whiteboard in development environment such as Microsoft NetMeeting but it does not work well in all cases.
Answer 2:
There are seven lean principles of software development:
Following are some steps that can be followed by Organization A which follows Waterfall Model to incorporate lean principle:
1. Eliminate Waste: Some of the reasons for causing waste in software development according to [9] are, partially completed work, no. of defects, constantly changing requirements. These wastes are generally caused by boundaries of different functions due to lost knowledge and delays. The organization should try to deliver in frequent iterations and have a retrospective meeting after each iteration asking what went wrong. [10]
2. Amplify Learning: According to [9], increasing feedback from the customer should be incorporated and testing should immediately followed by coding such that defects doesn’t stack up. Allow decide as late as possible policy and explore the available options such that enough knowledge is available.
3. Decide as late as possible: According to [10], principle puts emphasis on doing breadth first search instead of depth first search. Breadth first search includes exploring various options instead drilling deep into one single topic unlike waterfall model. They should consider top highest features and try to decide as late as possible when there is enough knowledge available and delaying decision can make things worse.
4. Deliver as fast as possible: According to [10], the organization should try to deliver the product faster compared to traditional waterfall model. Iterative waterfall model can be used to give frequent deliverables to customer. In first iterations only include minimum requirements and then iteratively frequent build can be used based on customer feedback.
5. Empower the team: This principle emphasis on allowing team to make its own decision and defines tasks of management to help and support the teams. Allow team to make their own commitments in all stages of waterfall development lifecycle and keep all staff motivated by purpose [10].
6. Build Integrity Within: Build the product with frequent iterations and allow customer to test the product (same as iterative waterfall with small iterations and frequent delivery). Allow developers and customers to talk and hence they can understand requirement easily and information flow is bidirectional and small in size [10].
7. See things as Whole: As previously stated start with minimum requirements and add the modules. Ensure that module does not have defect and also perform regression testing. Measurements should be taken to optimize the team as whole in waterfall model at coding section the teams should collaborate to find new things.
Some steps that can be followed by Organization B which uses SCRUM.
1. Eliminate Waste: It is the duty of scrum master to identify the waste that to be eliminated by team and categorizes them into two types 1. The waste that can be eliminated 2. Waste that require some effort to remove. Scrum master approach their team with suggestion for improvement [11].
2. Amplify Learning: In scrum, after each sprint team does a retrospective meeting to understand what went well and what didn’t. They add features into iteration backlog that are going to be implemented in next sprint and limit the WIP (Work in Progress) up to 3-4 items and it can increase the productivity of development. [11]
3. Decide as late as possible: Put larger and less defined task into iteration backlog and developed detail definition when there is more information available about product and enough knowledge is gained. [11]
4. Deliver as fast as possible: Continuous integration feature can be used instead of integration week and that’s how scrum teams can build product faster in short sprint times and can deliver customers frequently [11].
5. Empower the team: Instead of working on many items at one time they must do their own work. While switching between various tasks and trying to focus on many different things at same time can lead to become overloaded and overwhelmed hence individual team member must be motivated to do their own task. [11]
6. Build Integrity Within: Using automated testing environment and following test driven development and it changes the way how team thinks about scrum and turns the process of requirement validation into requirement generation [11].
7. See things as Whole: The team member should collaborate on the various phases and then they should explore try to improve collaboration. And as the collaboration increases the collective knowledge about software increases and each team member gets insight into each other’s responsibilities [11].
References:
[1] Prashant Baheti, Laurie Williams, Edward Gehringer, David Stotts, Jason McC. Smith, ‘Distributed Pair Programming: Empirical Studies and Supporting Environments’, http://collaboration.csc.ncsu.edu/laurie/Papers/TR02-010.pdf, 2002
[2] Hanks, Brian F, ‘Distributed Pair Programming: An Empirical Study’, 4th Conference on Extreme Programming and Agile Methods, Calgary, Canada, pp. 81-91, August 15-18, 2004
[3] Julia Schenk, Lutz Prechelt, Stephan Salinger, ‘Distributed-Pair Programming Can Work Well and Is Not Just Distributed Pair-Programming’, ICSE Companion’14,pp. 74-83, May 31 ‘ June 7, 2014, Hyderabad, India
[4 Ho, Chih-Wei, et al. “Sangam: a distributed pair programming plug-in for Eclipse.” Proceedings of the 2004 OOPSLA workshop on eclipse technology eXchange. ACM, 2004.
[5] Stephan Lukosch, Till Schummer, ‘Enabling Distributed Pair Programming in Eclipse’, 10th European Conference on Computer-Supported Cooperative Work. 2007.
[6] Devide, John Vijay Sena, et al. “Jazz Sangam: A real-time tool for distributed pair programming on a team development platform.” Workshop on Infrastructure for Research in Collaborative Software Engineering, Atlanta, GA. 2008
[7] Nick v. Flor, ‘Globally Distributed Software Development and pair programming’, Communications Of the ACM, October 2006/Vol. 49, No. 10
[8] David Stotts, Laurie Williams, Nachiappan Nagappan, Prashant Baheti, Dennis Jen, Anne Jackson, ‘Virtual Teaming: Experiments and Experiences with Distributed Pair Programming’
[9] Mary Poppendieck, Michael A. Cusumano , ‘Lean Software Development: A Tutorial’, IEEE software, 2012
[10] Kelly Waters, ‘All about Agile’, http://www.allaboutagile.com/lean-principles-1-eliminate-waste, 23 Aug, 2010.
[11] The Lean of Scrum, Microsoft Whitepaper, https://msdn.microsoft.com/enus/library/jj161049.aspx