# COMP0233 - Day 8 (1st December 2022) :::info ## :tada: Welcome to the 8th day! :books: Software project management ### Today Today we will look at - :handshake: different approaches to software project management - how to collaborate well - :paw_prints: issue tracking ::: :::warning | Room | groups | |--- | --- | | 1.05 | 1, 3, 8, 12, 15, 18, 21| | 1.21 |4, 5, 9, 10, 13, 19, 20| | 4.06 | 2, 6, 7, 11, 14, 16,| ::: :::danger **Only use zoom if you are connecting remotely or need subtitles** Remember to `rename` yourself by clicking on your zoom name (in the participants list) and change it to: `SXXX` where XXX is the room number (105, 121 or 406 or 000 for the online attendees). If you disconnect and connect again, please rename yourself again. **Use Youtube If you are in class*** ⏯ [streaming - youtube](https://youtu.be/wP-8UXt6Ufs) **UPDATED** ::: ### What was discussed during the last 2 weeks #### Making code easier to use for others - packaging - command line interface #### Structuring work in large software projects: - waterfall and agile - Issue tracking - What can go wrong: - Goals / requirements - Time allocation - Communication ### Poll Go to [Mentimeter](https://www.menti.com/alcg8jfjoh9y) (code: 13 89 73 22). We will answer some questions about development methodologies! ### Role-playing exercise (Part 1) :::info We will simulate the development process on a large software project. Within your group, allocate the following **roles**: 1 **Principal Investigator** (project manager) 1 **external collaborator** (client) 1 or 2 **students** (developers) Each role will have different priorities, and you will need to work together to achieve your goal. Some things are not specified, so you may need to make your own decisions! Depending on your role, look at the instructions: Role | Issue | Description Student |[:hash::four::eight:](https://github.com/UCL-COMP0233-22-23/RSE-Classwork/issues/48) | Ask for details, implement -|-|- PI|[:hash::four::nine:](https://github.com/UCL-COMP0233-22-23/RSE-Classwork/issues/49)| Ensure steps are followed and agreed on, monitor time Collaborator |[:hash::five::zero:](https://github.com/UCL-COMP0233-22-23/RSE-Classwork/issues/50) | Check requirements are met When in your groups, make sure that everyone knows their role and what the goal is. You have 20 minutes to discuss and come up with a solution based on the given information! ::: ### Discussion of Part 1 First, answer a quick question on [Mentimeter](https://www.menti.com/alcg8jfjoh9y)! :::warning :question: In your groups, discuss how the exercise went, and leave notes below. Some possible topics: - What steps did we skip, if any? - Was the separation of steps useful? Did having firm decisions help in future steps? - How did you communicate? What tools did/would you use? - What do you see as limitations of this approach? How applicable would it be in a research environment? ::: - Group 1: -We did not skip any steps -Yes the separation of steps was useful. -We talked in person. -We cannot code separately. - Group 2: - we did not skip any steps. - PI talked with developers and then talked with the client. - the separation of steps is useful. - Group 3: -We discussed very well. We skiped steps of coding part, showing software to client, running in terminal - Group 4: -we did not skip any steps -the separation of steps allowed us to have clear idea of what was to be done -we communicated in person -clear documentation of requirements are required to get information across - Group 5: - Group 6: - Group 7: - we are clearly excellent actors. we have a detailed idea of what we want but no code to show for it unfortunately. print('sad face ":(("') - Group 8: - Group 9: - Group 10: -The fact that the CSV file wasn't provided caused some confusion. -PI created a github reposatory to share files. Added the students as collaborators. - Group 11: - No steps skipped - We all had an idea of what steps to take (as the student's perspective). - We all observed the student's perspective working on the code and suggesting different approaches on how to tackle the problem. Google was the best tool. - I can see that if there were too many "students" on the team, it will result in conflict of ideas. - Group 12: - Detailed design was skipped, we expected one another to understand our expectations implicitly. - Detailed descisions more helpful than firm ones. - To communicate we mainly used talking, but shared typed info for specific detail. - Waterfall approach very innefficient. Continuous dialogue is more effective. - Group 13: Division of work is not clear. - Group 14: - No steps were skipped. - We mainly communicated orally, but we also used GitHub to work collaboratively. - Group 15: - Did not skip anything - - Group 16: - We skipped CITATION file. - Yes, it was and it did. - We communicated verbally. We would use discord and pull requests if were necessary. - It is hard to plan everything at first and agree all the steps with collaborator beforehand. - Group 17: - Group 18: - Process took a long time - did not skip steps but get to making a detailed structure - Project manager was good at ironing out details - ensuring that problems in the future wouldn't occur - Communicated via project manager verbally - Very slow :( - Group 19: - Group 20: We skip the test and showing it to the client. - Group 21: Waterfall method isn't the most effective for software development. Coming up with all the steps and processes before coding is quite time consuming. A more agile approach would be useful, especially considering we had to make changes at the very end. ### Role-playing exercise (Part 2) :::info For this exercise, we will try a more agile approach. You will work in short cycles, adding one or more features in each cycle. At each cycle, make sure you have something that works, even if it’s not the complete product. Your roles are the same as before. We have updated the previous issues :arrow_up: with what to look for in this new setting. You will have around 15'. Try to go through at least 2 cycles. It's fine if you don't add all the features! We want you to focus on how to communicate and make decisions. ::: :::warning :question: As before, discuss in groups and leave notes below. - Was the additional flexibility helpful or problematic? - What risks do you expect if working like this? How would you anticipate or prevent them? - How applicable would this be in a research environment? ::: - Group 1: -Yes. We were able to adjust and get tasks done quicker. -Risks: confusion. -Not very applicable if a big team is involved. - Group 2: - Group 3: - It was helpful, but the time was a bit short. - It was a bit problematic in a sense that clients can have multiple requests and not everything was i was implemented yet. - Risk: overwhelmed by the client requests, too much to achieve by the team. - How to adress: manage client expectations better, divide requirements into sprints agreed with the clientcan be achieved. - Very applicable into a research environment: things change a lot and the client and developers should agree on content before moving on. - Group 4: - Group 5: - Group 6: - Group 7: - we didn't have enough time. - Group 8: - Group 9: - Group 10: - Group 11: - The additional flexibility was nice - Risk: too much contribution at one time if there are multiple people on the same task. Debugging may become an issue if quite a few people are working on it at the same time. To avoid this, a limitation on the number of features can be set to prevent overwhelming changes. - This approach seems far more flexible and gives more freedom, suitable for a research environment where constant changes would be made to the analysis. - Group 12: - Flexibility was good - We worked in a flatter structure, so we were all working simultaneously, but this would be harder with a bigger group which had more subdivisions. - The agile approach would work well in a smaller group of coders with a similar skillset and style. - Group 13: - Group 14: - Wish we had more time :) - Can be difficult to predict the end-product, therefore testing and documentation need to be updated with every sprint - Would be applicable in a research environment that cahnges continuously - Group 15: - Much more convinence in agile. We can split the function for different person if we have already define the funtion and the interface. - Group 16: - Group 17: - Group 18: - More satisfaction after shorter amount of time - code is not optimised on first submission but having results is better than nothing - need more time :(( - makes changing code/finer details of the plan in the future to suit the requirements better easier - Group 19: - Group 20: - Sometime we cannot really implement well what the client want. - We need more time. - Group 21: - Group X: - Spent much time on making the code more robust and optimising the code. ### Issue tracking https://docs.github.com/en/issues/tracking-your-work-with-issues/about-issues ### Feedback Please, fill the [3/4-course feedback questionnaire](https://moodle.ucl.ac.uk/mod/questionnaire/view.php?id=4462993).