Day 1- Welcome & Kick-off
- Introductions (Lead: MJ)
Why OpenLMIS Expand |
---|
Widget Connector |
---|
url | https://www.youtube.com/watch?v=NBaISrhvLnQ |
---|
|
|
- Recap Project Background (Lead: MJ)
- News/Announcements (to provide context)
- 3.3 release marks end of Vaccine phase
- GAVI presentations including OpenSRP integration, open source Reporting stack
- Quick review of Dec. 7, 2017 group kick-off outcomes
- Team Canvas (Brandon has photos/paper canvas)
- Budget (from slides)
- Timeline (from slides)
- Team Composition
- Review structure diagram (also below)
- Parking Lot (Brandon has photos/paper)
- Agenda Review (Lead: MJ)
- Ground Rules (Lead: MJ)
Meeting Notes Ground Rules: Be Present Inclusive Conversation with no assumptions (as much as possible) Clarifying between decision making and brainstorming Voting for temperature takes Time box & stay on task Take notes and be transparent in communication
Introductions: Elias - JSI eLMIS core developer Craig - Ona Health Technical Lead Peter - CTO Ona Vishva - JSI QA Ashraf - JSI Team lead Josh - Village Reach OpenLMIS Architect Brandon - VillageReach OpenLMIS Core Team Dev Manager Matt - Ona CEO Mary Jo - VillageReach OpenLMIS Product Manager Muhammad - JSI logistics information system support team
- Announcements:
- VillageReach Staffing Updates
- Brandon will be shifting into a strategy and leadership governance role
- Nick Reid, the UI developer, is no longer with VillageReach
- Please review Mary Jo's key trip takeaways
- If you're not familiar with the OpenLMIS 3.3 demo, please connect and begin to familiarize yourself with it.
- The Implementer Toolkit is a document that describes how you implement OpenLMIS
- Project Review
- Why are we here?
- We want to globally harmonize versions of eLMIS and OpenLMIS
- Provide an upgrade path for implementations so they can more easily upgrade
- Deliver feature parity in line with other current requests
- Can we flag who we can build with?
- Malawi, Zambia and Tanzania are potential candidates
- Zambia and Tanzania have added the requirements in this Gap analysis. Malawi has reviewed these and added additional complimentary features
- Goals of funding
- We want to close the gap in Tanzania and Zambia
- Provide an upgrade path for Tanzania and Zambia
- Grow the community
- Create a development workforce regionally based that can improve sustainability of the platform and leverage diverse opinions and experiences
- Deliverables
- Phase 1 (April and May)
- Scheduled and approved roadmap
- Team diagram with roles
- Environments setup and development team up to speed
- Phase 2 (see slide)
- How to Estimate (Lead: Brandon)
- WHY we estimate
- acknowledge the super rough estimate and prioritization (show google sheet)
- Story Points and Epic Sizes – setting common baselines
- Skillsets - how we identify
- Team assignments - how we will do it (later)
- Priority (later)
- Flag areas where we can take a phased approach or simplify scope to meet the goal.
- Break into teams
- Prep: Create template for estimate/component/skillsets cards; ask Craig and Josh for review. ALSO create a slide to summarize team assignment.
- Meeting Notes
- Why are we estimating? - So we can track our progress throughout this engagement
- They want a schedule with monthly outputs
- We will be developing in an agile methodology internally and report out externally to donors
- We are estimating now so we can identify how difficult each task is, we will identify the components affected, skills, dependencies and flags for errors
- BY FRIDAY - A PRIORITIZED BACKLOG DUE
- How we will do it?
- Each group will get a color coded card. There is one card for each of the 24 features. Each color indicates a grouping of features
- If there are multiple ways to solve a problem, we need to clearly define this in a separate sheet
- If there are subtasks that can be done independently, we need to define these as separate sheets
- Dependencies: If it's related to another feature, we need to write the title of the dependency. We likely won't get down to fine grained detail.
- Size: We want to put work into buckets. The initial size is meant to be rough. After that, we need to assign points numerically to be able to measure. We will not convert to points this week. We just want to leave with Ticket, Small, Medium, Large, Infinate
- We are defining epics here, not features
- The epic defines a set of new functionalities that add value. They are categories of work that have many lower-level features, ideas and work to begin achieving it.
- We should have someone taking notes in each story describing the solutions that we are proposing
- Priority will be assessed at a later point
- Lunch: Fail-Fest: Past OpenLMIS lessons learned (Lead/introduce: Brandon)
- share lessons learned? history of forking? examples of multiple partners re-doing work or going in separate directions?
- Discussion had:
- Ashraf asked about micro-services and versioning. specifically asking about Malawi.
- Brandon shared that over the last year, we worked hard on the backend JAVA code extensibility however we didn't go deep into the UI side.
- Gap Scope Review/Estimation (Lead: Mary Jo and Craig)
- Overview of Gap features spreadsheet
- Mary Jo: Requisitions
- Craig: User Personalization (and notifications)
- 24 feature pages (some large in scope, some small)
- reports (13 wiki pages with 2 pages listing out multiple reports)
- Discuss any other priorities not reflected or any changes to requirements the team recommends
- Wrap-up (Lead: Mary Jo)
- Mini-retrospective: what's working and what's not
- Remind about parking lot and ground rules
Day 2- Day 2 Welcome (Lead: MJ)
- Agenda Review
- Any changes to agenda, ground rules, etc.
- Gap Scope Review/Estimation (Lead: Ashraf/Peter )
- Overview of Gap features spreadsheet
- Ashraf and Peter: Reports
- 24 feature pages (some large in scope, some small)
- reports (13 wiki pages with 2 pages listing out multiple reports)
- Discuss any other priorities not reflected or any changes to requirements the team recommends
Reporting by Muhammad Ahmed (Unlicensed), Ashraf Presentation: https://docs.google.com/presentation/d/1ZJjvb8hoUC_k3RK06Bw0eeQz4c1yepBgFTA7hGuNufc/edit?usp=sharing Gap Reports OpenlmisV3.pptx - Reporting Complexities
- PDF/xls outputs are by Jasper
- HTML is done with Angular
- Permissions - can be home facility or supervision
- Canned Reports
- Custom Reporting "tool" - There's a syntax built-in to OpenLMIS
- Operational Reports like a pick list
- Craig: Are there any performance hits/issues?
- Ashraf: Yes, we experienced so we had to do discrete improvements. We did use some batching approaches to address the performance.
- These batching approaches can use PostgreSQL materialized views as well as an ETL process, if needed.
- Themes from the day:
- User facilities
- User access model is derived from role, program, and supervisory node assigned to the user.
- Report features
- Exports
- PDF and Excel downloads
- Send data to Jasper, then Jasper returns the reports
- Permissions
- Does a supervisor with permission in a district and permissions to specific facilities in the district have permission to only those facilities or all district facilities?
- Right now only to the facilities they have explicit access to
- Facility managers would like to see aggregate reports, but only dis-aggregate to facilities they have access to
- This may expose information facility managers shouldn't have access to (if there are a total of 4 facilities, and they have access to 3 facilities plus the aggregate they can deduce the 4th, which they do not have explicit access to)
OpenLMIS Reporting Strategy - data pump patterns
- Goal to implement upgrading and services
- Data pump for microservices is defined by the service providing it (similar to an API) and publishes it (ATOM feed)
- Lunch: UI discussion (Lead: Ashraf and Josh)
- Spike on JS Frameworks - Ashraf summarize/report out
- Mobile Strategy - Josh to summarize Mobile Strategy doc and way forward
- Resourcing for the Gap (VR no longer has a UI lead resource)
Discussion Notes: - Josh highlighted that there is a significant amount of code that is already in OpenLMIS that is written in AngularJS 1.x.
- Josh referenced Nick's proposal: UI Architecture v7 (moving business logic outside of java script, progressive web apps, webpack)
- Ashraf's presentation:
View file |
---|
name | Angular vs ReactJS.pptx |
---|
height | 150 |
---|
|
- Peter asked if we could look into re-usability as another framing question.
- Josh - One approach is to find a part of the app that can be rewritten in another framework.
- Josh - UI Router is the core component that we should probably spike with other technologies.
- From the mobile strategy document consider re-writing stock management.
- Most of the performance issues that were observed were not because of API calls and back and forth with the server.
- Spikes were written to test if ng-react and ng-vue to see if it benefits the performance.
- Matt: Preference for going with react over vue for mobile stock management.
- The design process and developer on boarding was not discussed.
- There is no funding to rewrite the whole application in a new framework.
- This brainstorming session did not include everyone that that this issue concerns. Eg: SolDevel Developers who have the most knowledge about the current application.
- It would be better to move this conversation to technical meetings as well as the developer forum.
- Matt: We need to quickly decide on this. This influences staffing for the gap project.
- Josh Zamor as the architect, would be the contact person for this issue.
- Matt: are there reports that need to be mobile? is there space to discuss the vision and strategy to accommodate new features that would position OpenLMIS better in the market.
Interfaces Unfortunately it was challenging to take notes during this conversation and it was very circular. - OpenLMIS is not a facility registry. We will follow HL7 FHIR for facilities (locations)
- When countries don't have a functioning facility registry?
- We will be the master temporarily.
What we have today? - representations of location and devices in FHIR
What we need to do? - spike on tooling for facility registry ??
Locations - Gap Scope Review/Estimation (Lead: Ashraf/Elias and Brandon)
- Overview of Gap features spreadsheet
- Brandon: Fulfillment
- Ashraf/Elias: Equipment
- 24 feature pages (some large in scope, some small)
- reports (13 wiki pages with 2 pages listing out multiple reports)
- Discuss any other priorities not reflected or any changes to requirements the team recommends
- Day 2 Wrap-up (Lead: MJ)
Day 3
- How we collaborate (Lead: Brandon)
- See section 4 from Dec 7 slides – Brandon update it for LESS scrum and for our team structure
- Prep: Updated slides + Josh content; also Team ILL sync up about what team we are bringing/proposing
- Team Composition
- Talk through each partner's team membership and their contribution to the global services
- Team autonomy, component ownership and success - Josh?
- smaller teams (~2 people) not the entire organization
- contract with each team has criteria for team success
- milestones to check on whether team is on track
- global leadership won't get involved in the team's business unless/until it is not meeting expectations
- if so, we reserve right to dissolve and reform the team
Needs | VR | Ona | JSI |
---|
Java developers (Java 8, Springboot) | Java 8, Springboot 1.4+ | Java 8 | Java 8, Swing, Spring, Spring boot | Knows v3 codebase (back and front) | Back and front built most of the existing 7+ feature services | Minimal Understanding |
| Microservices architecture | Design, Consul and domain splitting (right sizing) | Understanding of Components |
| RESTful API Design | Yes and evolving | Knowledgeable in API Design for other projects | Yes | SCRUM knowledge methods | Scrum of scrums, LeSS | Agile teams, but minimal understanding of OpenLMIS | Yes (moderate level) | DevOps (dockerization, AWS, Ansible, monitoring) | Basic AWS, strong on Docker, not on Ansible ours is outdated in Chef, good log centralization and search, need to get better on tracing and internal service monitoring for use | AWS, Ansible, Docker, Monitoring, Automation, Security, Terraform, Packer, Basic Kubernetes and ECS experience, RabbitMQ, MQTT | Docker, AWS, Jenkin | Frontend framework (Angular, React, etc.) | Angular | React, Om | Angular, vue.js | Mobile | No | Android Native, React Native, Syncing |
| Reporting stack (Druid, Superset, NiFi, Kafka, HDFS, Jasper, Metabase) | Jasper, Tableu, "data pumps" | Druid, Superset, NiFi, Kafka, HDFS | Jasper, Metabase, Talend, learning about NiFI and cloud computing | Integrations (list out the systems which are potential for OpenLMIS to integrate with) | RapidPro, Nexleaf Coldtrace | DHIS2, RapidPro, Chatbots, OpenMRS, ODK | Integration with EPICOR, MACS, mSupply, DHIS2 | Domain (supply chain and logistics) Experience and knowledge of end users | Strong LMIS history | Deep Health Domain experience | Supply chain, logistics, forecasting, quantification | Business analysis skillset | Supply chain | Health domain, scalable solutions, defining requirements, end user design | Supply chain, user requirements, landscape analysis | UI/UX Design | Drop shadows, design workshop | Deep understanding of web service and mobile, HCI process, running design workshops |
| Enterprise architecture | Vision for domain boundaries and standards based teams... Interop standards of building one-offs. | Understanding of best practices in developing national health infrastructure in partnership with MOH. Robust experience in developing multiple national and global scale products. |
| Standards (FHIR, mCSD, GS1, OAUTH2) | mCSD, GS1, Oauth2 | CSD, HL7 v2, IHE PIX/PDQ, XForms, OAUTH |
| Database skills | Postgres, MySQL, SQL Server | PostgreSQL, MySQL, CouchDB, MongoDB, ElastiCache, Redis, InfluxDB, ActiveMQ | Oracle, MySQL, PostgreSQL, SQL Server | Open Source Community | Strong transparency actions (open documentation and guidance), community engagement, mentoring developers on working in the open. | Running OpenSRP and partnering with other communities (OpenMRS, DHIS2, RapidPro, ODK), Strong code review, constructive criticism, architecture review, always-be-commiting, and knowledge sharing culture |
| Build tooling and developer practices | Jenkins, Trunk based development | Travis-CI, Drone, Github Flow, Git Flow |
|
Team started to discuss what each team wants to work on: JSI - Area where we want to catch up on and learn about (micro services and whatever UI framework we move forward with, the reporting stack - DRUID)
- We bring experiences in everything else
- Desire to focus on the weaker areas (interfaces, micro services, reporting)
- Bring a lot of knowledge and experience on what was implemented in TZ and Zambia
- JSI would like to support lead on the designing and application of the reporting
- Experience on Docker and would like to share that knowledge
- Elias: not so interested in reports. Interest in React. Everything else from reports
- M: reports and analytics and cloud computing, containers, etc.
Ona - Would like to lead on the infrastructure and devops of reporting
- Devops on microservices
- Mobile, when possible
- Interfaces (DHIS2, sms)
- Would like to avoid using Angular
- Strategic areas we’d like to learn/gain
- Transparency approach
- Governance process
- SCRUM approach
VR - Standards based interoperability and knowledgeable about FHIR and standards
- Can work across the full stack (strong docker experience)
- Weaker on AWS and other devops since we aren’t implementing
- Leading arch and micro services (REST, web architecture, extensibility)
- Strong transparency on everything and working in the open (continuous delivery/integration)
- Next Steps (Lead: MJ)
- Plan June or July development kick off meeting in East Africa (Kenya/Zambia/?)
- Read-out and approvals to Product Committee, PATH/DS or Governance Committee
Team StructureTentative team structure based on Dec. 7, 2017 meeting:
source: https://boardthing.com/board/5a2f5126b2d40b061d0c0e19 |