实习日志 / English / Journals / Journal 1: Company Background and Work Environment

Journal 1: Company Background and Work Environment

中文 | English

Organisation and Project

This internship is the placement component of COMPSCI 778, a compulsory course in the Master of Information Technology (MInfoTech). It runs full-time for 10 weeks, 400 hours in total. The internship is organised by the Auckland ICT Graduate School, set up jointly by the University of Auckland and the University of Waikato, and the MInfoTech is awarded jointly by both universities. It takes the form of a Challenge programme, in which student teams work with an industry partner on real business problems. This intake's partner is AWS, and the project, the AWS AI Challenge, is run the way a real IT project would be.

The School hosts the project and AWS takes part as the industry partner. AWS sets the project briefs and assigns each team an industry mentor. The School assigns each team an academic supervisor, and a tutor looks after day-to-day matters. Thirteen teams took part in this intake. The first week was an intensive induction covering team formation, research and design thinking, and a bidding round for projects. Our team won Scenario 8: designing an AI agent that handles claims for an insurer called Northwind Insurance. Northwind is a fictional company created for the brief, and the industry mentor plays its business side, answering our questions from the point of view of the business, its needs and its value.

Working Rhythm

The internship runs full-time, at about 40 hours a week. Each morning we hold a standup with the tutor to go over the previous day's progress and the plan for the day. The project runs in two-week iterations. Each one opens with a planning meeting and closes with a showcase: in turn the prototype, the MVP, the validation prototype and the final showcase, followed by a poster session judged by industry reviewers. Every two weeks we also meet separately with the academic supervisor and the industry mentor to report overall progress and each member's own work, and to hear their advice.

Team Structure

There are five of us. Once development settled down, each member took charge of one technical area. I am responsible for the behaviour design of the product agent and the claimant-side experience. The other four teammates look after the backend API and AWS integration, data persistence along with policy and claim history data, the staff workbench, and evidence materials and test data. Each member is primarily responsible for the code and documents in their own area and also takes part in acceptance checks across areas. Beyond my own area, I set the goals for each iteration, maintain the team's Kanban board and act as maintainer of the code repository. In that role I keep the repository conventions and hold the overall direction of the product, while specific design questions are decided in team meetings.

Workflow

Almost all of our collaboration happens on GitHub, and the workflow is built around the Kanban board.

The board is the team's centre of progress. Each iteration's goals are broken down into task cards that name an owner, dependencies and acceptance criteria, and tasks are sized in working hours. In the later stages each member takes on about eight hours of work a day. At a glance, the board shows how far the project has come, how much work each person is carrying and which tasks are waiting on someone else. Standups and planning meetings are run around it.

A piece of work starts as a card on the board. The card maps to an issue that states the problem and what counts as done. Once work begins, a pull request is opened and linked to that issue, and after review and merge the task is complete. The board updates itself as the pull request moves along, so nobody has to maintain it by hand. Of the thirteen teams, ours was the only one to sync repository tasks with the Kanban board automatically.

Questions that need a joint decision, such as API fields, permissions or dependencies across areas, are settled in the repository's Discussions. The outcomes flow back into issues and task cards, and Discussions are not used to sign off ordinary tasks. So far the team has opened more than seventy discussions.

Working with AI is part of this workflow too. Most of the team use AI coding tools, so the workflow conventions are written for people and tools alike: the rule file at the entrance to the repository speaks to teammates and to the tools they use. Written records and automatic status updates mean nobody needs to hold the whole state of the project in their head to know what to do next.