| Panel | ||||
|---|---|---|---|---|
| ||||
What did we do well? |
- Developer calls have been better at sticking to the time
- Weekly meetings & stand-ups to get updated
- Longer sprints are better
- Coming back to story-owners/epic maintainers
- Everyone got familiar with docker
- Well organized agenda during hackathon, convenient rooms
- Very nice and friendly people in project
- Technologies used
- well organized hackathon
- We have a quite good and active DevOps team
- Documenting the decisions on confluence is good
- Hackathons are very helpful to discuss the issues
- PR's are reviewed swiftly
- People
- As a new member I feel greatly welcomed
- Very happy that the team has bonded that much more
- Nice climate in the team
- people spend time trying to understand your problem and help
- teamwork + work together even though geographically separated
| Panel | ||||
|---|---|---|---|---|
| ||||
What should we have done better? |
Process
- Not sure about the new sprint model (feedback: we just started)
- scrum process is still bad - 4 weeks sprint, no product owner, no team wide planning, too much JIRA flow, too less actual benefits of flow. (feedback: we now have story owners)
- sometimes the development and deployment process are quite messy. Is maybe needed to define and follow some guidelines.
- Testing before releases
Communication
- Too much talk (has gotten better though)
- Speed of decision making → need to just decide! (feedback: use mailing list + some things are complex/require design process)
- Where are the research parts? (feedback: initiative→ propose youself)
- Description of tickets in JIRA could be more detailed. sometimes they are not very expressive (we could add fields to the description like: current state, expected state) (feedback: initiative→ ask story owners for more detail (they can delegate). Also: confluence pages (requirements/design) + current state is original slidewiki.org. Also see improvements below)
- Sometimes giving tickets for services to new people is problematic because service maintainers missing giving an introduction and do not explain what have to be done how (feedback: see above + improvements below)
- Bringing new devleopers into the project is incredibly difficult & time consuming (feedback, see above + improvements below)
- Locate original programmers of some component or service to ask question about doubt. With owners is more easy but still difficult. (feedback: use git blame or look at commits of file)
Tools
- Phantom errors - random change of some hash values in custom_modules/ folder
- Deploying changes to submodules is very hard!
- Fluxible is so(!!) time consuming
- React & flux are still awfull
- Style guide? Need es-lint check (better now than fixing everything in future)
- No semantic-UI please
- Using atom when webstorm is free for universities
Suggested Improvements retrospective participants
People
- We are >18 people → one big team. => split responsibilities to max 5 person team
- Split responsibilities → service owners, frontend team, devops team, search team, etc... (feedback: we try to have everyone work on everything as much possible (front-end, back-end). We already have story/epic owners)
- We may benefit from peer code reviews (feedback: we try, but resource problem → assign more people to PR's yourself)
Tools
- We need a monitoring solution → google analytics, Newrelic, datadug (feedback: we do this → always looking for new open source solutions)
- Refactor to react stateless component if possible
- More unit tests (feedback: yes!)
Process
- Documentation
- Shorter discussion in confluence (making decisions) (feedback: mailing list for decisions. Perhaps use question-options-choice template used for discussion on http://tinyurl.com/zv7owof )
- More developers blogs
- A single document or section-by-section HTML linked pages that explains how to deploy system
- More knowledge spreading / interdisciplinary sessions
- Developer documentation with worked out examples + how to add /change different types of things
- Better connection to open source community
- More documentation for external devs
- Retrospectives more often
- Improve forward planning + road map (feedback: in progress, we have user stories 2017 excel sheet)
- Improve managing expectations of trial partners (feedback: in progress, we have user stories 2017 excel sheet, and form for trials to indicate what they want → https://goo.gl/forms/vpE2XREAAShaLSFs1Ben Wulff where can we see results? Should we add these in user stories 2017 excel sheet)
- Focus more on graphical design of our platform
- Delete merged branches (feedback: done during hackathon → everyone is present → "can we delete this?")
Actions
- Documentation on how to deploy SlideWiki, also for OSS dissemination/support (Kurt Junghanns Roy Meissner do you want to publish/extend the existing guide on the on developers blogs http://tinyurl.com/zpme2lh We can possibly also add materials from a tutorial on using docker during WebSci if it is accepted)
- More knowledge spreading presentations (Benjamin Wulff Klaas Andries de Graaf )
- Retrospectives more often (Klaas Andries de Graaf Benjamin Wulff )
- Developer documentation with worked out examples, also for OSS dissemination/support (on developers blogs? Kurt Junghanns Roy Meissner - can you link to this Prezi http://tinyurl.com/hzl3y6l on the developers blog? This is some documentation/example on how to use the flux and react architecture that I (Klaas Andries de Graaf) presented during Hackathon V1. Also, shall I make a post summarizing and combining http://tinyurl.com/zlq9wcy and http://tinyurl.com/z7o3eh4 and http://tinyurl.com/zw7buun for new devs and/or OSS people that want to join the project?)
- Peer code reviews → assign more people to PR's yourself. (All!)
- Add more code comments (All!)