Header image

How-To

Tech news

Có cần tài liệu thiết kế (design document) trong phát triển phần mềm Agile?

27/08/2021

177

Xin chào tất cả mọi người.

Tôi là Ueki – một thành viên của SupremeTech Co.,Ltd. Với vai trò là một Phó Giám đốc tôi hỗ trợ cho các dự án phát triển về mặt quản lý với các role như Project Management Office (PMO) hay Resource Management Office (RMO).

Sau khi đọc được một bài viết thú vị với chủ để mà tôi rất quan tâm là  lý do tại sao các programer không viết document , tôi đã có suy nghĩ đặt bút để viết nên bài viết này.

Có cần tài liệu thiết kế (design document) trong phát triển phần mềm Agile?

Mục lục

1. Tại sao nhiều dự án vẫn làm việc được mà không cần đến tài liệu thiết kế?

2. Vai trò Product backlog (và những hạn chế)

3. Vai trò của Design documents

4. Bạn hiểu rõ tầm quan trọng của Design documents nhưng nó lại quá phiền phức

5. Ba mẹo để ứng dụng tốt cả Product backlog và Design documents

6. Kết thúc

1. Tại sao nhiều dự án vẫn làm việc được mà không cần đến tài liệu thiết kế?

Trước khi đến Việt Nam, tôi từng là một system engineer tại một công ty SI ở Nhật Bản. Lúc đó chủ yếu các dự án phát triển theo mô hình waterfall, nên tuần tự công việc của chúng tôi sẽ là: tự viết design document, review, sau đó dựa trên design đó để tiến hành coding, tạo test cases, chạy test. Vì thế mà, tôi chưa từng nghĩ đến việc phát triển hệ thống mà không có design document.

Khi chuyển công việc sang một công ty chuyên về WEB, tôi đã rất shock khi thấy một số project vẫn chạy bình thường mà không hề có design document.

Chuyện xảy ra một thời gian trước đây khi tôi còn làm ở một công ty Offshore ở Việt Nam. Khi đó, tôi có tham gia vào một dự án từ Phase 2. Tôi có nhờ Project manager (PM) phụ trách Phase 1 chia sẻ cho tôi tài liệu về design document thì lại nhận được URL của một tool quản lý task có tên là Redmire, tool này được dự án sử dụng để quản lý Product Backlog.

PM đó nói với tôi rằng tất cả yêu cầu đều được mô tả trong ticket Redmine, nên đó chính là design document.

Lúc đó, khi tôi đặt ra câu hỏi “Nếu yêu cầu có thay đổi thì có update trong ticket đó không? “. Câu trả lời tôi nhận được là “Trong trường hợp đó, sẽ tạo ticket mới”. Nếu như vậy thì chẳng phải sẽ có trường hợp yêu cầu của 1 màn hình có thể bị trải dài ra nhiều ticket khác nhau, và ngược lại yêu cầu của nhiều màn hình có thể chỉ được gom lại trong một ticket hay sao? Như vậy thì những ticket Redmine đó không thể làm vai trò của một design document được.

Bỏ qua nhiều câu hỏi trong đầu, cuối cùng tôi đã bỏ ra vài tuần để tạo lại từ đầu design document của Phase1, trước khi bắt đầu Phase2. 

Người PM mà tôi vừa nhắc đến cũng là một thành viên thuộc team PMO của công ty, đến cả một người ở level này và có nhiều kinh nghiệm như thế mà cũng chấp thuận và làm theo cách này, quả thật lúc đó tôi đã rất shock. Thế nhưng, nếu như đã quen với mô hình phát triển Agile, họ chỉ cần nhận được tài liệu khái quát từ khách hàng, Product backlog hay whiteboard, thông qua việc thảo luận với khách hàng, họ sẽ không cần đến design document mà vẫn có thể tiến hành coding, do đó, dù ko nắm được tầm quan trọng của design document hay sự khác biệt giữa Product Backlog và design document thì họ vẫn có thể phát triển dự án được. 

bài blog tôi có nói đến ở phần đầu cũng đã viết “cho dù không có document cũng không có trở ngại gì cả”, nhưng đó lại là sự thật.

Vậy nên, nếu không cần design document mà vẫn có thể phát triển được thì design document cũng trở nên không cần thiết nữa sao?

Có thật sự không cần đến design document nếu đã có Product backlog không?

Thực ra, Product backlog và design đều được mô tả bằng chung một từ là “specification” nhưng vai trò của nó lại khác nhau.

Nói cách khác, không phải cái nào tốt hơn cái nào, mà là cả hai đều cần thiết cho các mục đích khác nhau. 

2. Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)

Ở SupremeTech, chúng tôi quản lý các Product backlog bằng các tool quản lý ticket như Backlog, Github issue, Redmine.

Chúng tôi sẽ quản lý 1 product backlog bằng những tickets được PO tạo ra, khi cần thiết sẽ cùng thảo luận, đặt Q&A ở phần comment, sau đó sẽ bổ sung những nội dung được quyết định cuối cùng vào phần overview của ticket đó.

Trong mô hình phát triển mà yêu cầu thường không được rõ ràng ở giai đoạn đầu như Agile, thì phương pháp này rất có hiệu quả và cho phép nhiều bên liên quan (Stakeholders) tham gia vào quá trình xây dựng yêu cầu để yêu cầu được tốt hơn.

Những product backlog item (PBI) đã hoàn thành sẽ được close, nếu có yêu cầu thay đổi thì sẽ tạo một ticket mới để các kĩ sư có thể chỉ cần tập trung vào phần hiện tại mình làm.

Vì có thể nhìn thấy được số lượng ticket, nó sẽ giúp bạn lên schedule dễ dàng hơn dựa theo estimate và cũng có thể thúc đẩy các engineer làm việc hiệu quả hơn thông qua các mục tiêu đã đề ra.

Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)
Quản lý Product backlog bằng Github issue

Mặt khác, nếu chỉ quản lý bằng  Product backlog, sẽ có những câu hỏi chỉ có thể trả lời bằng kí ức phát sinh như là “đâu là spec đúng hiện tại” hay “cái nào mới chính xác”.

Ví dụ ở Product backlog có những thông tin như sau:

1. Muốn develop màn hình A bao gồm các function A-1, A-2, A-3

2. Log các yêu cầu của màn hình A ở ticket ①

3. Engineer tiến hành develop → Close ticket ①

4. Thay đổi spec ở function A-1 và A-2 ở màn hình A

5. Log các yêu cầu thay đổi của function A-1, A-2 ở ticket ②

6. Engineer tiến hành develop → Close ticket ②

7. Thay đổi spec ở function A-2 ở màn hình A

8. Log các yêu cầu thay đổi của function A-2 ở ticket ③

9. Engineer tiến hành develop → Close ticket ③

Ở đây, nếu bạn muốn kiểm tra spec chính xác của màn hình A, bạn cần phải tìm tất cả các ticket ①②③  đã close và sắp xếp chúng theo thứ tự thời gian. (Trong ví dụ này, spec đúng của màn hình A bao gồm function A-1 được log ở ticket ②, function A-2 được log ở ticket ③ và function A-3 được log ở ticket ①).

Các ticket đã close có thể được tìm thấy bằng cách search trên tool quản lý ticket, nhưng nếu search bị sót 1 thông tin gì đó hoặc kết hợp sai, thì spec sai sẽ bị nhầm thành spec đúng.

Nếu bạn cố gắng xây dựng spec mới dựa theo cái đã bị nhầm trước đó, sự nhầm lẫn qua lại sẽ ngày một tăng lên.

Vai trò của Product backlog (và những hạn chế khi sử dụng nó như một tài liệu thiết kế)
Product backlog không phải vạn năng

Cũng có cách để tách ticket cho từng function A-1, A-2, A-3, nhưng ở ví dụ này nó chỉ là một function, và spec có thể thay đổi ngay cả chỉ với một image hay một button, vì vậy sẽ không thực tế nếu chia các yếu tố thành ticket được.

Cũng có ý kiến ​​cho rằng “những gì được viết trong code mới là đúng”, và nó có thể đúng trong trường hợp bây giờ, nhưng chưa chắc đã đúng hết như thế.

Vì không có gì đảm bảo rằng không có bug xảy ra nên không thể cho răng nội dung code là spec đúng được.

3. Vai trò của design document

Vậy tại sao chúng ta cần phải cần có một spec đúng?

Bạn hoàn toàn có thể implement dựa trên nội dung ghi trong Product backlog, nhưng chỉ nên duy trì điều đó trong một thời gian ngắn.

Ở mô hình phát triển Agile, chúng ta sẽ bắt đầu phát triển với một mô hình hệ thống nhỏ tối thiểu, thường trước hết chúng ta sẽ release MVP (Minimum Viable Product: Sản phẩm khả dụng tối thiểu), và liên tục cải thiện trong thời gian dài dựa theo feedback của người dùng.

Trường hợp các member tham gia dự án ngay từ đầu, nắm rõ ngọn ngành và spec thì có thể duy trì dự án mà không gặp vấn đề gì với Product backlog, tuy nhiên nếu có member mới join vào, hoặc ngược lại, các member cũ rời khỏi dự án vì nhiều lý do, thì khó có thể tránh khỏi nhiều hiểu lầm xảy ra nếu dự án được tiếp tục duy trì lâu dài.

Khi đó, cần phải có design document với những yêu cầu cơ bản chính xác và mới nhất ở thời điểm hiện tại để không phải chỉ truyền đạt với nhau bằng miệng.

Trước hết, trí nhớ của con người không phải lúc nào cũng hoàn chỉnh (duy trì thông tin đầy đủ và nhất quán), nên điều quan trọng là phải có một nơi (tài liệu) lưu giữ thông tin chính xác (source of truth) thay vì dựa vào trí nhớ.

Vì design là nội dung đã được thống nhất thông qua review của client và engineer, nên nếu có action nào khác với description trong product, thì có thể là bug hoặc đã bỏ sót thông tin.

Tóm lại, Product backlog hữu ích trong vòng đời phát triển (life cycle develop) ngắn hạn, còn design document có thể được coi là công cụ cần thiết để lưu trữ lâu dài.

Vai trò của design document
Cần phân biệt giữa Product backlog và design

4. Bạn hiểu rõ tầm quan trọng của Design document nhưng nó lại quá phiền phức

Tôi sẽ tạm dừng phần giải thích về vai trò của Product backlog hay design document ở đây.

Các engineer thường hay nói “Tôi hiểu design document rất quan trọng, nhưng tôi không có thời gian để tạo chúng”, hoặc “Nó không thú vị bằng viết code (tôi không có hứng thú).”

Những người như vậy thường tránh viết tài liệu vì họ muốn tập trung coding trong một khoảng thời gian đã được đề ra, nhưng nếu cứ tránh thì họ sẽ không tiến bộ và sẽ tạo nên một vòng luẩn quẩn ngày càng muốn né tránh.

Ở SupremeTech, chúng tôi phân chia và triển khai đầu công việc thành hai mảng là document và coding với hệ thống resource gồm có Business Analyst (BA) – người sẽ cùng với client và engineer triển khai yêu cầu thành Product backlog, design document, và Software Engineer (SE) – người sẽ phát triển phần mềm dựa trên những yêu cầu đó.

Việc tạo design document thường tập trung chủ yếu vào phase 0 đến 1 trong thời gian đầu của project, và một khi design document được tạo xong, phần còn lại chỉ là update các phần cần thay đổi, vì vậy giả sử bên SE phải update thì rào cản tâm lý cũng sẽ giảm đi đáng kể, do phần tài liệu mà họ cần phải làm chỉ là phần update.

Việc tạo design document ban đầu là một trong những nhiệm vụ của BA và thông qua quá trình này, họ có thể nắm được yêu cầu và hỗ trợ cho project với tư cách là spec holder.

Mặc dù vậy, khi quy mô MVP lớn hoặc trong trường hợp tiến hành dự án đã được phát triển từ phía công ty khác nhưng lại không có design document thì gánh nặng cho BA sẽ rất lớn. Trong trường hợp đó, Japanese Communicator (JC) sẽ đảm nhiệm phần biên/phiên dịch để có tạo ra design. Trong career path của chúng tôi, những JC sau này đều sẽ có hướng phát triển thành BA nên điều này cũng vừa có ích cho việc đào tạo công việc BA cho JC để phát triển trong tương lại.

Bằng cách phân chia công việc như thế này, việc tạo/ duy trì design document được thực hiện như yếu tố cần thiết để phát triển phần mềm, tương tự như coding của SE, hoặc việc phân chia task, lập kế hoạch và quản lý tiến độ của PM là không thể thiếu.

Bạn hiểu rõ tầm quan trọng của Design document nhưng nó lại quá phiền phức

5.  Ba cách để ứng dụng tốt cả Product Backlog và Design document

Trước đây khi còn là Senior BA tại công ty phát triển phần mềm Offshore tại Việt Nam, cũng đã từng điều hành dự án sử dụng cả Product backlog và Design.

Nên tôi muốn giới thiệu cho mọi người một số mẹo mà cá nhân tôi thấy dễ thực hiện.

1. Update timing

Product backlog được sử dụng để thiết lập spec trong life cycle develop ngắn hạn nên thường xuyên được update.

Mặt khác, design document dùng để duy trì lâu dài không yêu cầu phải cập nhật realtime, nên tôi nghĩ nó có thể sắp xếp thời gian để update nó khi mà yêu cầu đã ổn định hơn, không còn thay đổi nhiều nữa. Cụ thể, thời điểm SE bắt đầu coding, hay thời điểm tiếp nhận yêu cầu từ client, yêu cầu sẽ được đưa lên Product backlog, sau đó chúng ta mới tiến hành update design document.

Tất nhiên, điều này không áp dụng nếu project được phát triển dựa hoàn toàn trên design document.

2. Sử dụng tool

Bạn nên sử dụng tool quản lý ticket để có thể quản lý Product backlog. Có rất nhiều tool khác nhau như Backlog, Github issue, Redmine,… nhưng bạn có thể lựa chọn tuỳ thích miễn là tool đó có thể assign function, set milestones, change status, change notifications. Github issues có thể sẽ hữu ích cho engineer khi họ còn có thể sử dụng Github để quản lý task và code version cùng 1 chỗ.

Tôi thường thấy nhiều trường hợp sử dụng Spreadsheet để quản lý Product backlog, nhưng tôi nghĩ đây lại là một antipattern. Ở life cycle develop ngắn hạn hay được update thường xuyên, Spreadsheet lại không có function thông báo về các cập nhật, nên khả năng sẽ xảy ra nguy cơ không để ý và bỏ quên nội dung nếu có ai đó add/change/delete chúng.

Hơn nữa, so với Product backlog, ta thường sử dụng Spreadsheet cho các design có tần suất update thấp. Các thay đổi sẽ bị lưu lại trên sheet lịch sử thay đổi. Cũng có ý kiến khắt khe cho rằng không nên sử dụng Spreadsheet cho bất cứ cái gì ngoại trừ cho bảng tính (excel), nhưng tôi nghĩ dùng công cụ gì cũng được miễn là nó được sử dụng một cách thích hợp với nhu cầu trên thực tế.

3. Có cần tách riêng giữa client và internal không 

Tốt hơn là nên tách Product backlog thành một bên cho client (client và BA sử dụng) và một bên cho internal (Project members như BA, PM, SE sử dụng).

Đầu tiên phải kể đến vấn đề ngôn ngữ. Việc chuẩn bị product backlog cần những  đổi phức tạp, hoặc mang tính khái quát cao về product sẽ như thế nào, nên nhiều trường hợp client muốn thảo luận bằng ngôn ngữ mẹ đẻ (tiếng Nhật hoặc tiếng Anh) càng nhiều càng tốt. Nhưng kĩ sư người Việt lại không sử dụng thành thạo tiếng Nhật hoặc tiếng Anh giao tiếp, nên Communicator sẽ phải dịch sang tiếng Việt hoặc tiếng Anh, và như thế nhiều ngôn ngữ sẽ bị trộn lẫn và đoạn hội thoại sẽ trở nên khó đọc.

Tiếp theo là vấn đề về độ chính xác, chi tiết của thông tin. Việc spec thay đổi thường xảy ra trong quá trình thảo luận, nhưng có nguy cơ là PBI của client được bắt đầu triển khai sớm ngay cả khi yêu cầu đó vẫn đang trong giai đoạn thảo luân, dẫn đến phải làm lại. Ngoài ra, nếu nhiều yêu cầu được thảo luận trong một ticket hoặc ngược lại, các yêu cầu tương tự được thảo luận trong nhiều ticket, thì phải tách riêng/ tổng hợp nếu cần và sau đó truyền đạt lại cho kĩ sư, như thế sẽ tránh hiểu sai về nội dung công việc.

Từ những điểm trên, chúng tôi đã áp dụng phương pháp tách từng tool và quản lý Product backlog cho client giao tiếp bằng tiếng Nhật và Product backlog cho internal giao tiếp bằng tiếng Anh hoặc tiếng Việt.

Mặt khác, vì cần phải có được sự thống nhất của cả client và engineer sau khi tạo xong design document, nên sẽ tốt hơn nếu viết bằng tiếng Anh trên Spreadsheet chung để mọi người có thể cùng thấy. Nếu dịch những gì đã tạo từ tiếng Nhật sang tiếng Việt, bạn sẽ phải quản lý 2 phiên bản tiếng Nhật và tiếng Việt, và nếu có một bản được chỉnh sửa, nhưng bản kia lại bị sót, thì khả năng hiểu sai spec giữa client và engineer sẽ xảy ra.

Dù được viết bằng tiếng Anh, design cũng chỉ đơn giản là mô tả các yêu cầu với nội dung giải thích dài thành một câu giải thích ngắn hơn, nên trừ khi client của bạn là người không thích tiếng Anh, thì nó vẫn có thể chấp nhận được.

Ba cách để ứng dụng tốt cả Product Backlog và Design document
Luồng thực hiện khi tóm tắt Tips 1-3

Flow hoạt động này chỉ là phương pháp hay nhất từ ​​kinh nghiệm của riêng tôi nên không có nghĩa là sẽ áp dụng được trong mọi tình huống.

Cơ bản, tôi nghĩ sẽ không sao khi lựa chọn work flow hay tool dựa trên đặc điểm của từng dự án, sở thích và kinh nghiệm của các bên liên quan (stakeholder), hoặc là quan điểm tôn giáo (^^).

Nếu design documentation hiện tại của bạn không hữu dụng nhiều, bạn có thể lấy cách làm này để tham khảo.

6. Kết thúc

Bài viết này dùng để truyền đạt vai trò của design document và cách tương tác cho những bạn không hiểu vì sao lại cần design document hoặc những bạn đang gặp vấn đề về cách vận dụng nó.

Ngay cả ở công ty SupremeTech, tôi cũng muốn hỗ trợ và truyền đạt cho các member của chúng tôi có thể nhận thức rõ tính quan trọng của design document và những rủi ro khi không có nó, cũng như để phân bổ nguồn nhân lực cần thiết.

※ Bài viết này được phiên dịch từ bản tiếng Nhật được viết trên Enlyt Blog.

Related Blog

satellite project for healthcare management system

Success stories

+0

    A Satellite Project for Healthcare Management Systems

    In the ever-evolving landscape of healthcare, SupremeTech emerges as a beacon of innovation, dedicated to empowering healthcare centers and healthcare management systems. This journey unfolds through the art of creating satellite projects, commitment to deadlines, adaptability in action, and the extra mile with offshore development. Let's delve into how SupremeTech carefully designs each satellite project to prioritize value, precision, and adaptability in healthcare solutions. The Art of Creating Satellite Projects Understanding the need for scalability in healthcare management systems The healthcare landscape is ever-evolving, and SupremeTech has acknowledged the need for scalable solutions. In this segment, we explore the crucial role of scalability in healthcare management systems.  Healthcare Management System (CMS), which SupremeTech developed as an offshore development solution, offers you seamless access to update citizens' health information. This user-friendly platform empowers you to stay connected and informed. Moreover, our systems facilitate smooth communication between citizens and healthcare providers, enabling remote consultations and health ranking services. This not only enhances care accessibility, particularly for individuals in remote areas or with limited mobility but also elevates citizen engagement and satisfaction.Embracing citizen engagement and promoting self-care, our digitized healthcare management system instills a sense of empowerment and responsibility for personal health. Through easy-to-use interfaces and intuitive mobile applications, individuals can engage in activities that promote better health. From setting fitness goals, monitoring exercise routines, and tracking nutrition, to accessing educational resources and connecting with support communities, a digitized health management system empowers citizens to make informed decisions and adopt healthy lifestyle choices. SupremeTech's approach to create satellite projects from large-scale projects. SupremeTech's special skill is making big ideas into easy-to-handle projects. Explore how we extract satellite projects from large-scale initiatives, ensuring not just size but also adaptability and precision. Recognizing that an optimal Agile team size ranges between 7 to 10 individuals, we want to highlight that SupremeTech takes deliberate measures to imbue adaptability into each satellite project. This signifies that these projects are engineered to evolve, pivot, and effortlessly incorporate new features or modifications as necessary, guaranteeing a responsive and dynamic reaction to evolving requirements.  That's the reason why SupremeTech has decided to create a good satellite project with the Healthcare Management System (CMS) and application to adapt to new requests from clients who want to create a new health tracking system in a new city. Deadline Management: A Supreme Commitment Importance of meeting deadlines in healthcare projects. Time is a precious commodity in healthcare. The timely implementation of projects directly impacts everyone's healthcare. SupremeTech recognizes that delays can have far-reaching consequences, and meeting deadlines is not just a goal but a necessity. SupremeTech's strategies for effective project timeline management. SupremeTech makes projects that can change and adapt easily to fit different needs. We focus on making these projects precise and flexible to meet the ever-changing demands. Comprehensive Planning: The journey begins with meticulous planning. Before a project even starts, a comprehensive roadmap is laid out, detailing every milestone and task with our clients. This strategic planning allows for a clear understanding of the project scope, potential challenges, and the critical path to success.Clear Communication Channels: Communication is the key to effective project timeline management. SupremeTech establishes clear and transparent communication channels, both internally and with clients. This ensures that everyone involved is on the same page, minimizing misunderstandings and facilitating quick decision-making. Risk Management Strategies: Every project comes with inherent risks. SupremeTech, however, doesn't just identify risks; it proactively manages them. Robust risk management strategies are in place to anticipate and address potential challenges, preventing them from derailing the project timeline. Adaptability in Action In the intricate world of healthcare projects, where change is constant, SupremeTech orchestrates a seamless dance, showcasing the vital need for adaptability. As projects evolve, SupremeTech's flexibility shines through, effortlessly accommodating new requests and embracing change with unparalleled finesse. Clients witness a dynamic partner who not only keeps pace with evolving needs but actively thrives in the ever-shifting landscape of healthcare project execution. Benefits for All Explore the tangible benefits that SupremeTech's proactive approach brings to Public Health sectors, Healthcare centers, and Healthcare systems. From improved scalability to streamlined processes and enhanced employee engagement, discover how SupremeTech creates a positive impact for all. Offshore Development: The Extra Mile Dive into the technological backbone that supports SupremeTech's success. Learn how SupremeTech transcends geographical boundaries, bringing together global collaboration for unparalleled efficiency. Development systems and technologies Below are the resources and technologies we use to develop the services: Details of entrustment: Design, Implementation, Testing, Migration, Maintenance & Operation Platform: CMS, Native App Development language: PHP (Laravel), Kotlin, Swift  Let SupremeTech help you to start your healthcare management system now! As our journey concludes, embark on your adventure by visiting SupremeTech. Witness the culmination of expertise, dedication, and innovation. For a new beginning in healthcare management solutions, contact SupremeTech and be a part of a story that goes beyond success - a story of continual innovation and transformation in healthcare management. Don't wait, take the first step towards a more efficient and effective healthcare system today.

    06/12/2023

    4

    Success stories

    +0

      06/12/2023

      4

      A Satellite Project for Healthcare Management Systems

      line mini app to digital transform customer service

      Success stories

      +0

        LINE Mini App: Digital Transform Customer Service with Digital Point Cards

        SupremeTech has been on an impressive journey of building and developing, positively impacting customers. One of our recent and innovative projects involved meeting our client's request to launch digital point cards integrated in Line Mini App. These cards allow customers to accumulate points or make payments within their network of stores. Previously, our client used physical cards for this purpose. However, recognizing the potential of using digital means to encourage more transactions, they swiftly moved forward. Initiating suitable solutions for a traditional issue With a commitment to customer satisfaction and delivering the best app experience, we proved our capabilities in doing this project. Understanding the client's needs, we embarked on research to provide a viable solution for developing and maintaining a mobile application for issuing and managing digital point cards. The app enables users to effortlessly carry and use their point cards on their smartphones, with key features including card issuance, displaying corresponding barcodes, and generating one-time barcodes for transactions. Developing a Loyalty App on Line App: What Sets it Apart A unique requirement for this project was the development of a mini-app on the Line app. Line, a popular international communication and calling app developed by LINE Corporation, offers various gaming and platform applications for users' entertainment and interaction within a virtual environment. This was an entirely new platform for SupremeTech, and despite no prior experience, the team immediately dove into research. Developing the app on Line presented challenges such as limited customization options for interface and user experience, adherence to Line's regulations, and potential limitations or lack of support for specific features. Overcoming Challenges and Successfully Launching the Line Mini-App Despite these challenges, SupremeTech successfully completed the Line mini-app project. Leveraging the versatility of React and Node.js, the team maximized Line's API and SDK potential for seamless integration and interaction with Line App features. Additionally, research was conducted to combine with other systems for data retrieval. After six months of dedicated efforts, the Loyalty App on Line App was successfully released. Highlighted Features This mobile app can issue digital point cards by entering user information or linking with physical cards to display information as barcodes. Key features include: Card Issuance: Allows customers to issue digital point cards.Barcode Display: Displays corresponding barcodes for each digital point card.One-time Barcodes: Generates one-time barcodes for specific transactions or interactions. Contributing to the Business Ecosystem This technological solution significantly contributes to the current business ecosystem by optimizing customer loyalty programs. It encourages customer transactions across all business service points. The app seamlessly connects with customer data systems, ensuring a smooth experience for the business and its customers. If you want to modernize your business and enterprise ecosystem with a cutting-edge loyalty app, don't hesitate to contact SupremeTech. We're here to help your business thrive.

        05/12/2023

        10

        Success stories

        +0

          05/12/2023

          10

          LINE Mini App: Digital Transform Customer Service with Digital Point Cards

          shopify order tracking app for the food industry

          Success stories

          +0

            Shopify Order Tracking App for The Food Industry

            TakeOut is a Shopify application that allows restaurants and food industry businesses to streamline their takeout service. Instead of relying on a third-party application to sell and deliver food online, customers can order directly from the restaurant with this Shopify order tracking app. Sounds like a delicious way to increase profit engagement with customers! Almost everyone who lives in an urban area has had food delivered to them. Of course, there have always been a few more options when it comes to takeout. There's the stereotypical "Chinese takeout" that comes in a paper oyster shell tossed into a bag with disposable chopsticks and a handful of fortune cookies. If only one of those fortune cookies had told us about the possibilities of future food delivery and takeout! Today, all of your favorite foods are available for takeout or delivery.  Shopify Serves Small Restaurant Businesses The project began when a client approached us with the concept of giving small businesses a way to reduce their operating costs. Although there are many benefits to being listed on popular delivery and takeout websites and applications, but these benefits come at a financial cost. For some businesses, this is fine; just pay the fee and keep selling! However, some businesses prefer to keep these external costs to a minimum. Utilizing Shopify's Popularity in Japan In Japan, Shopify has become increasingly popular. Our partner client saw an opportunity to capitalize on this popularity and create an application that gives restaurants a choice. Now, Japanese restaurants can choose to sell their products through a well-known service or put more effort into developing their own brand and selling their food directly to hungry end users. TakeOut Functions for Foodies The first function of TakeOut is the call function. This allows customers to place a takeout order from the restaurant's Shopify website. The application shows where the food is in the pipeline, from the order being received, to being in the kitchen, to being ready for pickup. When the food is close to being ready, the application can send a push notification to notify the customer. If a client restaurant wants to add additional customization to the pipeline or takeout application, we can accommodate any request. Again, this is the beauty of Shopify: with a qualified team, the customization possibilities are nearly endless! User-friendliness is Delicious! Furthermore, adding the TakeOut application to a restaurant's Shopify is incredibly easy. In most cases, you won't need a development team at all. We've created a step-by-step guide on how to integrate the app into an existing Shopify store. All the restaurant owner has to do is follow the steps, then they're selling their deliciousness directly to customers. Similar to how customers might want to customize their food order, if there's something that needs to be changed, we can do the customization for the restaurant's Shopify.  TakeOut Challenges: Multiple Locations The project itself was not too difficult. A small team developed the application over the course of three months. SupremeTech had a lot of experience working with Shopify and our partner Fracta on other projects.   We worked seamlessly with our client partner. Our Japanese business analyst coordinated communication between the engineering team and Japanese stakeholders. However, despite our best efforts, there was one particular challenge that nearly tripped us up! Development projects rarely go by without some challenge or miscommunication. However, during the TakeOut project, we were able to adapt and complete the project on time. We worked under the assumption that the Shopify stores we were developing TakeOut for were stand-alone locations. We developed the app under without considering businesses with multiple locations. Due to Shopify's policy, this required some last-minute tinkering. Fortunately, we were able to power through the last minute adjustments. Sudden changes are common in our industry. Nonetheless, we learned valuable lesson about adapting when the client's specifications change.  Serving Customers With TakeOut TakeOut was a Shopify eCommerce application that we developed to help small businesses. We continue to work closely with our partner client to add new features to the app as the market dictates. To date, TakeOut's client restaurants and food lovers have praised its user-friendly interface. We're excited to see how the platform continues to change the way we do eCommerce in the future. Contact SupremeTech if you want the same Shopify order tracking app or any custom Shopify solutions. We make your business smarter and smoother!

            23/11/2023

            70

            Success stories

            +0

              23/11/2023

              70

              Shopify Order Tracking App for The Food Industry

              golang for devops

              How-To

              Knowledge

              Tech news

              +0

                Golang for DevOps: Empowering Infrastructure as Code and Automation

                In the realm of DevOps, efficiency, agility, and automation are paramount. This article explores how the Go programming language, often referred to as Golang, plays a significant role in DevOps by enabling infrastructure as code, automation scripts, and deployment tools. We will also discuss how Golang development services can support DevOps teams in achieving their goals. Understanding DevOps Before diving into Golang's role in DevOps, let's clarify what DevOps is all about. DevOps is a set of practices that aims to break down the traditional silos between development and IT operations teams. It promotes collaboration, communication, and automation to streamline software development and deployment processes. Infrastructure as Code with Golang Infrastructure as Code (IaC) is a cornerstone of DevOps, allowing infrastructure to be managed and provisioned using code. Golang is a powerful language for creating IaC because of its simplicity, efficiency, and excellent support for concurrent programming. Declarative IaC: Golang enables the creation of declarative IaC scripts, where you specify the desired state of your infrastructure. You can use tools like Terraform and Pulumi, which are written in Go, to define your infrastructure in a human-readable format. Golang's syntax is clean and easy to understand, making it an excellent choice for this purpose.Concurrency: DevOps often involves managing multiple resources and services concurrently. Golang's built-in support for concurrency with Goroutines and Channels ensures that you can manage your infrastructure efficiently. This is especially valuable when dealing with large-scale, distributed systems.Performance: Golang is known for its performance. When you need to apply changes to your infrastructure rapidly, Golang's speed can significantly reduce the time it takes to provision and manage resources, contributing to overall DevOps efficiency. Automation Scripts in Golang Automation is at the heart of DevOps, as it allows for repetitive tasks to be executed with precision and consistency. Golang's design makes it a perfect fit for writing automation scripts. Cross-platform Compatibility: Golang can compile code for multiple operating systems and architectures. This means that a single Golang script can run on various platforms, reducing the need to maintain separate scripts for different environments.Static Typing: Golang's static typing system provides robust error checking, helping to catch potential issues early in the development process. This feature is particularly beneficial when writing scripts that interact with critical systems.Rich Standard Library: Golang's standard library offers a wealth of packages for working with APIs, databases, networking, and more. DevOps professionals can leverage these packages to streamline the development of automation scripts.Ease of Deployment: Golang's ability to produce standalone binaries simplifies deployment. You don't need to worry about dependencies or runtime environments when distributing your scripts. Deployment Tools and Golang Development Services Deploying applications and services efficiently is a core aspect of DevOps. Golang can be a valuable ally in creating deployment tools that ensure smooth and reliable application delivery. Custom Deployment Pipelines: Golang allows DevOps teams to create custom deployment pipelines tailored to their specific requirements. You can build tools that handle everything from continuous integration to deployment, monitoring, and scaling.Integration with Containerization: Containers are a fundamental component of modern DevOps, and Golang is well-suited for creating container-related tools. Many container orchestration tools, like Kubernetes, are written in Golang, showcasing its capability in this area.Microservices Deployment: DevOps often involves the deployment of microservices. Golang's small binary size and efficient concurrency handling make it an excellent choice for managing and orchestrating microservices within a larger system. Support from Golang Development Services Golang development services provide valuable support to DevOps teams aiming to leverage the language for infrastructure as code, automation, and deployment. Here are some ways these services can assist: Consultation: Golang development services can offer expert advice and guidance on the best practices for using Golang in your DevOps processes. They can help you determine the most suitable tools and frameworks for your specific needs.Custom Tooling: Golang development services can create custom tools and scripts tailored to your infrastructure and deployment requirements. This ensures that your DevOps processes are as efficient as possible.Integration: Golang development services can integrate Golang-based tools with your existing systems, ensuring a seamless transition and coexistence with your current infrastructure.Maintenance and Support: DevOps is an ongoing process, and Golang development services can provide ongoing maintenance and support for the tools and scripts they develop, helping you keep your DevOps pipelines running smoothly. Conclusion Golang's simplicity, efficiency, and robust support for concurrent programming make it a valuable asset for DevOps teams looking to implement infrastructure as code, automation, and deployment processes. The language's capabilities, combined with the support of Golang development services, enable DevOps professionals to streamline their workflows, achieve higher efficiency, and meet the demands of modern, agile software development and deployment. Whether you are creating infrastructure as code, automation scripts, or deployment tools, Golang is a versatile and powerful choice in the DevOps toolbox. Contact us for your tailored Golang development services.

                17/11/2023

                88

                How-To

                +2

                • Knowledge
                • Tech news

                17/11/2023

                88

                Golang for DevOps: Empowering Infrastructure as Code and Automation

                Post banner imagePost banner image
                Customize software background

                Want to customize a software for your business?