Daily Tasks Reporting Automation

Daily Tasks Reporting Automation

Every day we spend 15-40 minutes sharing our work status during the Daily / Stand Up / STUM / YTB meetings. However, we often forget to document it or do it inaccurately. This happens because it is annoying to work with the graphical task management systems. Below I'm presenting my experience in automating this daily routine using textual UI - Human API

  1. Project/Task management systems
  2. Human API Benefits:
  3. Implementation
  4. Examples (TL/DR)


Project/Task management systems

I'm sure you are already working with at least one of these.

Of the top of my head: Trello, Jira, Azure Devops, Monday and of course Excel.

No matter what you choose they all have the following:

Strengths

  • Transparency - You know the shared work's status.
  • Unification- Common language. Feature, User Story, Task, Bug, Sprint etc.
  • Flow management- Rules and policies to regulate state changes.
  • Predictability- Ability to plan the future work based on the history.

Weakness: Human factor

All the benefits achievable only if the data saved in the system is accurate and complete- the more the better.

How many times did you hear/tell/think:

  • "It was couple of hours, was lazy to open a task/bug"
  • "Forgot to add working hours to this task"
  • "Had lot of context switches. No idea how much total time did it take"
  • "I'll fill it tomorrow before the daily meeting"
  • "Any way nobody will read this..."


Human API Benefits:

  1. Simplifying the world to the minimal needed set of statuses and actions.
  2. Easy arithmetic calculations make time proportions more evident. e.g.:

  • Reporting +2 hours on a planned task
  • Reporting +4 hours on a planned bug
  • Oh! Forgot to open new bug on yesterdays production issue: Reporting 2 estimated hours, adding +4 hours real time spent. Adding a title and comment.
  • Total for yesterday: +2 +4 +4 = 10 hours of work. Very close to the real time proportion.

3. Input validations:

  • Title format (e.g. <10 words)
  • Check whether parent was set.
  • Enforce comment and time estimation on the new tasks.
  • Enforce comment on a task which you spent time on or closed.

Implementation

Assumptions:

  • Automate everything you do recurrently.
  • Typing is quicker than clicking.
  • Use API as much as you can.
  • DIY program = fun. Customizable solution configuration, reconfiguration, rereconfiguration.... = not fun.

Definitions:

Task's lifetime and your?action:

  • Creating?a task- NEW task. No work performed on the task yet.
  • Working?on a task- ACTIVE task. You are investing your and only your time in the task.
  • Informing?other worker you are waiting for him- BLOCKED task. I mean active waiting: sending reminders, escalating etc.
  • Reaching?the desired state- CLOSED task. From now on - only new tasks and bugs.
  • Commenting on any task or bug.

Human API single task reporting format:

[<ParentType> <ParentID> #<ParentTitle>] -> <ChildType> <ChildID> #<ChildTitle> :actions: <CommaSeparatedActions>        

  • ParentType - Task/Bug/UserStory/Feature etc.
  • ParentID - System UID, if empty parent will be created.
  • ParentTitle - Brief summary of the job to be done. 5-7 words.
  • ChildType - Task/Bug
  • ChildID - System UID, if empty - child will be created.
  • ChildTitle - Brief summary of the job to be done. 5-7 words.
  • CommaSeparatedActions - Actions to be performed on the Child.

Content sample:

[user_story 1000 #Front-end CI/CD] -> task 1001 #Nginx Configuration CI/CD :actions:
[task 1001 #Front-end CI/CD] -> task 1003 #CORS configuration :actions:
[user_story 1000 #Front-end CI/CD] -> bug 1002 #Python version deprecated :actions:        


Human API file types:

  • daily.hapi - Current status retrieved from Task Management System using API. This is a baseline - in case you want to see the status before the changes.
  • daily_input.hapi - Manual reporting file. The actions you want to document since the last Daily.
  • daily_output.hapi - Generated YTB report. A small bonus- activities' summary in a notes format. Used in the daily meetings to have a quick view over the completed work

Examples (TL/DR)

daily.hapi Example

These are the sections you have in the file:

  • NEW - you are not working on it and do not plan to work on it today. New, Reopen etc.
  • ACTIVE - You were working/ are working/ will work on it today.
  • BLOCKED - Waiting for human response. e.g. On hold, In review, Blocked, Waiting for QA, Waiting For deployment etc.
  • CLOSED - Nobody will work on it. e.g. Closed, Resolved etc.

*Scroll to the right to see complete line

worker_id: [email protected]
>NEW:
[user_story 1000 #Front-end CI/CD] -> task 1001 #Nginx Configuration CI/CD :actions:

>ACTIVE:
[user_story 1002 #Backend] -> task 1003 # Kubernetes Service :actions:
[user_story 1004 #Sprint 888 CI/CD Bugs] -> bug 1005 # Prod Front-end deployment failed :actions:

>BLOCKED:
[user_story 1000 #Front-end CI/CD] -> task 1007 #Nginx Configuration CORS :actions:

>CLOSED:
[user_story 1002 #Backend] -> bug 1009 # Kubernetes Infrastructure :actions:        

daily_input.hapi Example 1. Reporting task changes.

Daily actions - actions you do on your tasks: Status changes, setting estimated time, updating completed work time, commenting.

Before the daily meeting you extract current status from Task Management System using API. At the beginning this is a copy of "daily.hapi".

After filling the actions you've performed on the tasks you push the changes back.

Below is an example of the textual format for reporting workers' daily actions.

*Scroll to the right to see complete line

>ClLOSED
[user_story 1002 #Backend] -> task 1003 # Kubernetes Service :actions: +2, comment Created YAML file generator.
[user_story 1002 #Backend] -> bug # QA Nginx cache configuration :actions: 2, +1, comment Time units misconfiguration- hours instead of seconds.        

Actions being performed on these work items:

  • Task 1003- Add 2 hours to the completed work. (+2)
  • Task 1003- Add a comment "Created YAML file generator".
  • Task 1003- Move to closed. (It is in the ">CLOSED" section of the report)
  • Bug QA Nginx- New bug (Created in the Task Management System on the report push) with 2 hours estimation (2)
  • Bug QA Nginx- Add 1 hour to the completed work (+1)
  • Bug QA Nginx- Add a comment "Time units misconfiguration....".
  • Bug QA Nginx- Move to closed. (It is in the ">CLOSED" section of the report)

Filled by each team member. Validated for input/format errors and pushed to the Task Management System via API.

Simulation

Let's translate the "daily.hapi Example" to human language.

Yesterday morning I planned to work on the following:

  • ACTIVE Task (id: 1003) "Kubernetes Service" under Backend user story - create new deployment process for the backend service.
  • ACTIVE Bug (id: 1005) "Prod Front-end deployment failed" - need to find the reason and deploy the fix. If the problem is more complicated than a couple of hours fix- make a workaround and add user_story to the backlog- will be discussed in the Sprint Planning.
  • BLOCKED Task (id: 1007) "Nginx Configuration CORS" is blocked - waiting to receive all the needed URLs from other team members.

worker_id:[email protected]
>NEW:
[user_story 1000 #Front-end CI/CD] -> task 1001 #Nginx Configuration CI/CD :actions:

>ACTIVE:
[user_story 1002 #Backend] -> task 1003 # Kubernetes Service :actions:
[user_story 1004 #Sprint 888 CI/CD Bugs] -> bug 1005 # Prod Front-end deployment failed :actions:

>BLOCKED:
[user_story 1000 #Front-end CI/CD] -> task 1007 #Nginx Configuration CORS :actions:

>CLOSED:
[user_story 1002 #Backend] -> bug 1009 # Kubernetes Infrastructure :actions:        

Despite the expectations my yesterday's work included:

  • BLOCKED Task (id: 1007) "Nginx Configuration CORS": I received all the needed URLs, changed the configuration and deployed to PROD- took me 2 hours.
  • ACTIVE Bug (id: 1005) "Prod Front-end deployment failed": spent 2 hours to find it fails on some "Untested bug". So I created the new Task "User sign out failure test"- it should take two hours to add new test-case to the ci/cd. BTW it's under a new user story "Front-end test enhancemet"
  • NEW Task (id: 1001) "Nginx Configuration CI/CD": Since I was already into the Front-End ci/cd user story I took another task from NEW and spent 6 hours on it. Deployed my changes to the ci/cd process and closed the task. Unfortunately my change broke the QA environment's ci/cd... So I created a new Bug (No ID yet) "Nginx config generator breaks QA". Expecting it to take 8 hours of work. Spent an hour yesterday and going to work on it entire day today.
  • ACTIVE Task "Kubernetes Service": Didn't work on it yesterday and not going to work on it today. Moving it back to NEW.

* Report lines are split before "->" because of the text editor's bug.

worker_id:[email protected]
>NEW:
[user_story #Front-end test enhancemet] -> task #User sign out failure test :actions: 2, comment New test use case related to bug 1005.
[user_story 1002 #Backend] -> task 1003 # Kubernetes Service :actions:

>ACTIVE:
[user_story 1000 #Front-end CI/CD] -> bug #Nginx config generator breaks QA :actions: 8, +1 comment After Changing worker type builds are failing in QA.

>BLOCKED:

>CLOSED:

[user_story 1004 #Sprint 888 CI/CD Bugs]
-> bug 1005 # Prod Front-end deployment failed :actions: +2, comment Untested bug found

[user_story 1000 #Front-end CI/CD] 
-> task 1001 #Nginx Configuration CI/CD :actions: +6, comment Changed worker type.

[user_story 1000 #Front-end CI/CD] 
-> task 1007 #Nginx Configuration CORS :actions: +2, comment Added proper CORS configuration into CI/CD.

[user_story 1002 #Backend] 
-> bug 1009 # Kubernetes Infrastructure :actions:        

  • Task 1007: BLOCKED -> CLOSED + 2 completed work hours + comment.
  • Task 1001: NEW -> CLOSED + comment + 6 completed work hours.
  • User_story 1000: As a result of our 1001 task we broke QA. ACTIVE + setting 8 hours work estimation + 1 completed work hour update.
  • Bug 1005: ACTIVE -> CLOSED + comment + 2 completed work hours update.
  • Created user_story "Front-end test enhancement".
  • Created NEW task "User sign out failure test" under the new user_stroy. Setting 2 hours work estimation + comment.
  • Task 1003: ACTIVE -> NEW. Since I will work on the recently created new bug in Front-end QA today.

daily_output.hapi (YTB report)

  • Lines with action "+hours" - go to "Yesterday"
  • Lines under ACTIVE - go to "Today"
  • Lines under BLOCKED - go to "Blocked"


[30/02/2023] Team member: horey

Y:

[user_story 1000 #Front-end CI/CD] -> 1011-Nginx config generator breaks QA

[user_story 1004 #Sprint 888 CI/CD Bugs] -> 1005 -Prod Front-end deployment failed

[user_story 1000 #Front-end CI/CD] -> 1001 #Nginx Configuration CI/CD

[user_story 1000 #Front-end CI/CD] -> 1007 #Nginx Configuration CORS

T:

[user_story 1000 #Front-end CI/CD] -> 1011-Nginx config generator breaks QA

B:

None

要查看或添加评论,请登录

Alexey Beley的更多文章

  • Implementing Cloudwatch alarm re-triggering

    Implementing Cloudwatch alarm re-triggering

    Introduction Solution (TL/DR) Real life flow Miscellaneous Introduction While improving my Serverless Alert System I…

  • Converting Identity-based into resource-based policies (a know-how)

    Converting Identity-based into resource-based policies (a know-how)

    (TL/DR Goto: Solution) Well, I am not going to explain you what are the Identity-based policies and Resource-based…

  • AWS Security Domain Tree

    AWS Security Domain Tree

    Errare humanum est (Making mistakes is human nature). Who can measure our mistakes’ consequences? As the infrastructure…

  • Protecting production from CI/CD

    Protecting production from CI/CD

    About this article Vulnerability explained in a nutshell More detailed presentation Terminology and concepts Security…

  • Reliable AWS Serverless Monitoring

    Reliable AWS Serverless Monitoring

    Monitoring in the cloud has some challenges. One of them is trusting your Monitoring system works as expected.

  • Bash script logger

    Bash script logger

    If only I could use logger and traceback in bash..

  • boto3 S3 upload

    boto3 S3 upload

    Foreword This article’s auditory Solution architecture AWS CLI vs boto3 comparison - sequential (no threads) AWS CLI vs…

  • If only I could "try and catch" in bash...

    If only I could "try and catch" in bash...

    From time to time we need to run heavy scripts with unpredictable IO behavior. Network glitches, lock-files locked etc.

社区洞察

其他会员也浏览了