This article is a machine translation of the contents of the following URL, which I wrote in Japanese:
https://qiita.com/Nana_777/items/84e3d2fd3ee793ac0083
Introduction
In the previous article, we introduced the basic functions.
In this article, we tried to see what would happen if multiple people were to share the development of a system's specifications, or if Kiro was unable to run due to traffic restrictions on Kiro and the implementation had to be temporarily carried out using a method other than Kiro, such as manual implementation.
[AWS] I tried out the popular Kiro features, including applying rule files and implementing from an architecture diagram [KIRO]
Explanation of the system used in this article
[Role of the system]
Calculator app
[Main tasks]
- Create a directory structure for the calculator app (models, views, controllers, tests, styles)
- Implement a CalculatorEngine class that performs basic arithmetic (addition, subtraction, multiplication, division)
- Implement error handling for division by zero, overflow, and invalid input
- Implementing a basic calculation flow
- Integrating the basic flow of inputting numbers → operators → inputting numbers → equal signs
- Implementing a decimal point calculation function
- Implementing a clear function
When multiple people share the development of the specifications for one system
What to do: Split the SPEC
As described in the Kiro documentation, SPEC can be divided into multiple specifications and managed.
By splitting the SPEC, implementation tasks can be carried out without conflict for each, allowing you to manage the specifications in a focused manner.
https://kiro.dev/docs/specs/best-practices/
How to split the SPEC
The SPEC file can be split manually, but you can also split it by receiving suggestions on how to split it in a chat with Kiro
Here, I typed in the chat, "This application will be developed by a team of multiple people. Can you split the SPEC?"
As a result, they proposed the following division method
- Front-end UI - UI components and styling
- Business logic - Calculation engine and data model
- Integration and testing - Controller and overall integration
When dividing by function, they proposed the following division
Function division plan
- Basic calculation function Four arithmetic operations (+, -, ×, ÷) Number input processing Calculation execution using equal sign (=) Basic calculation logic
- Input control function Decimal point input processing Backspace (delete) function Clear function (C, AC) Input validation and error handling
- UI and display function Display) Creating a calculator layout Implementing the display screen Button design and styling Responsive design
- Keyboard operation function (Keyboard Support) Keyboard event handling Key mapping Keyboard shortcuts Accessibility support
- Integration & Testing Integration of each function End-to-end testing Browser compatibility testing Final adjustments and debugging
This time, we divided the code into smaller sections by function
Splitting results
As a result of the splitting, three SPEC files were generated for each split folder
Should I delete the original SPEC?
As a result of splitting, the SPEC (calculator-app in the screenshot) that contains the overall specifications created at the beginning remains, but this can be deleted.
When splitting the SPEC, the requirements and specifications are also split, so you can also create a document that allows you to see the overall requirements and specifications in one file, so decide whether to keep or delete it as needed.
From the perspective of preventing mistakes when performing tasks, it is safer to delete it.
Task execution
When you are performing your assigned tasks, you can ask Kiro to run the SPEC in your assigned folder via chat, or press the "Start task" button on the task file.
This time, I requested "Please execute the calculator-ui-display task" in the Kiro chat.
When an interruption such as manual implementation occurs
What to do: Scan deliverables and sync with the task list status
Kiro not only executes tasks, but also allows you to check how far a task has progressed by scanning the current implementation content.
For example, when importing content from a different tool other than Kiro or manually implemented content, or when importing an existing system into Kiro and switching to SPEC development and operation, you can synchronize deliverables such as programs, their specifications, and the progress of tasks.
Tried it
Here, I tried importing the deliverables of a UI task created externally into the project in the state where SPEC was divided.
By executing the UI task "Update Task", it scans the current project's deliverables, determines how far the tasks have progressed, and updates the task list.
When you run "Update Tasks", you can see the results being scanned in the chat box.
As the verification progresses, tasks that have been confirmed to have been implemented will be marked as completed.
Tasks that have not been completed will not be marked as completed.
If you want to perform an incomplete task or a subsequent task, execute "Start tasks" for that task.
Conclusion
When I first tried Kiro, it generated a SPEC file that contained the overall requirements, specifications, and task list, so I wondered how to divide this among the team and proceed with development.
After reading Kiro's documentation and trying it myself, I found that it is possible to divide SPECs and import artifacts created outside Kiro, so I was able to reaffirm that it is a good tool that can be used in various development situations.
I look forward to future feature updates for Kiro, and would like to consider and verify various ways to use it and share the results.
Top comments (0)