vhandit

This Month I Learned posts are aimed to share what I have learned during the month such as my thoughts, recommend resources, tips, how-to, and so on. Vung Tau beach Engineering Levels I conducted a lot of meetings with HRM to define the standards for evaluation criteria, career path ladder, Personal Appraisal (PA) processes, and onboarding/offboarding processes. I knew more about the expectation from an HRM perspective for engineering levels evaluation criteria. For example Define many enough titles for a long career path development Define general criteria for each level How to calculate score when evaluation with weight matrix applied Anticipate risks before executing a process Team Engineering Lead Organization I collected ideas from different people When having no dedicated leader, every member of the team has a fairly chance to practice leadership skills Scalability strategy: development teams’ size, and new position nomination. Security Awareness Training I conducted this sharing...

Developers should be informed transparently about the next things that they are going to do since it impacts their mentality as well as their accountabilities. A view of Vung Tau beach First thing first, the Product Owner plays a very important role in understanding the business of the projects clearly and planning the User Stories for Development Teams. For Development Teams, we have two roles related to a project including Owner and Maintainer. The following are the definition and responsibilities for each role: Project Owner The Owner is normally assigned to the team that created the project at the beginning. It is known as the long-term project of the team. Therefore, the members of the Owner have almost knowledge of the projects including the history (i.e decisions made), business logic, and technologies used.  - Maintain a good system design (code) of the projects. Therefore, they are mandatory to review code (pull requests) from other teams. - Maintain the related documents ...

Software development can be understood simply as a program to receive inputs (i.e customer needs) and then produce outputs (i.e working software). It is worth it to know how many steps are in that program. When something gets stuck in a step, everyone is aware of that. The first painting of my son The General Process Big Picture There are two main factors in this picture including the people with roles and their interactions. All people involved in developing the product know their responsibilities clearly and how to make things done right. Therefore, a good collaboration can be reached. Product Roadmap Contribution It would be great for developers to know what the next features to work on are as well as when those features will be delivered. Therefore, the product roadmap is very important. The items in the roadmap should be contributed by ALL people involved in the product. Because software engineers directly develop, test, delivery, and monitor the software, they should also contrib...

 Historically, our company ubitec had started with a customer project. Agile/Scrum was our proposal for working with customers. Time by time, Agile/Scrum also became our culture for software development. To be successful with this development approach, we somehow needed to have a fast release for customers (i.e. every one week). Back then, we had a build tool Jenkins which was responsible for having sprint release packages for our customers. The build job pipelines contain some steps such as gathering the artifacts, checking the code convention, running the tests, building docker images, and packaging an archived file (a zip file). The set of tools involved in a pipeline is roughly called a toolchain. It is just a part of a bigger process called the DevOps toolchain. Source: https://www.ibm.com/blogs/cloud-archive/2016/11/devops-architecture-available-on-bluemix-garage-method-site/ DevOps is a proven method that fits Agile. Today,  it is even treated as a mandatory factor...

Agile is a fit for our company business. We use Scrum practices as our Agile framework. Eventually, Scrum is just a framework that helps us work together to develop, deliver, and maintain our products. Moreover, it is also a tool to grow the teams. By practicing Scrum long enough, we will gain the great following values: Commitment Focus Openness Respect Courage --- [1]. https://agilemanifesto.org [2]. https://www.scrumguides.org/scrum-guide.html

Using daily meetings for frequent course corrections. However, you should keep the meeting short because time is burn rate . Though good collaboration doesn't guarantee a project's success, poor collaboration almost always guarantees a project's failure What benefits does the daily meeting bring to you? - Keeps inexperienced developers and experienced ones on-track. - Avoids reinventing the wheel. - Limits  tumbleweed developers ' damage. - Leverages the entire team’s experience to solve problems quickly. - Improves team communication. - Helps every people have a big-picture point of view. Who are tumbleweed developers? We’ve all worked with a few tumbleweed developers. These developers lose direction and drift through their days. They wade through the random code and “improve” it, cleaning up method signatures, polishing algorithms, and reformatting brackets. Tumbleweed developers lack the discipline to finish any task you ask them to do and generally c...

Customer Needs My team already had a go-live app in a customer environment some months ago. We have been developing some new features for our next milestone. The situation is described in the picture below: We used Git for our codebase management. The go-live app running on our customer environment was at version ` v1 `. The latest sprint release was at version ` v7 ` for our developing app. Our customers wanted to have two separated release packages for our current sprint release. We all know that it was easy to ship the package to the developing app. However, the issue was that how we just picked some features needed for the go-live app. We called this package was a hotfix. Git Cherry-Picking Fortunately, we found that Git provided a way to achieve this task. Actually, we had all commits on the branch ` master ` already. We created a new branch called ` hotfix/v1.1 ` and we traced back which commits needed. We used cherry-picking for merging these commits to this branch....

The topic is about my experience on my first project with my freelance team. We implement the last step of this process which you can find in the end of this post. You might have heard of something like the following: Many customers don't know what they want. Yes, that's a fact. In order to help customers solve their needs, we'd better consult them or we provide a consulting service. The next questions is "how?". Our approach is enhancing the collaboration with customers or providing a design of customer interactions. Firstly, we create a website wireframe to express the idea of website's functionalities. For example: Source: Wikipedia And, the further step is that we make a running app based on the created wireframe where the real UI/UX is demonstrated. However, it is just a GUI/frontend with dummy data without interaction to a backend. Technically, that is just a html template which contains source code of HTML, CSS and Javascript. For exampl...

Passion for System Design After finishing a one year project, my longest stable team (lasted for 3 years) was separated into two smaller teams. Sadly, but that was a good chance for me to become a key member in my new team. My preferred skills were about system architectures; therefore most of the tasks of building the application structures were handled by me. In order to enhance my design system skills, I have spent much my time for reading books closely after work. These following books help me a lot. - Object-Oriented Thought Process | Matt Weisfeld - Head First Design Pattern  | Elisabeth Freeman and Kathy Sierra - Java 8 in Action: Lambdas, Streams, and Functional-style Programming | Alan Mycroft and Mario Fusco Junior Technical Architect I was requested to join a technical architect team (aka Team. Alpha) where I actually had gained experiences almost on interviewing candidates for my company (lol). Besides, I noticed myself must improve the skills of convinci...

https://www.scrum.org Scrum is not only designed for software development Scrum can be used for addressing any complex issues: 1. Research and identify viable markets, technologies, and product capabilities; 2. Develop products and enhancements; 3. Release products and enhancements, as frequently as many times per day; 4. Develop and sustain Cloud (online, secure, on-demand) and other operational environments for product use; and, 5. Sustain and renew products. Scrum Values is a key factor for building trust and respect among team members The five values are: 1. Commitment 2. Courage 3. Focus 4. Openness 5. Respect Daily Scrum's questions are more focused on inspection and adaption rather than the status 1. What did I do yesterday that helped the Development Team meet the Sprint Goal? 2. What will I do today to help the Development Team meet the Sprint Goal? 3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal? ...

Everyone talks about it, but not everyone knows what it is. Why DevOps? In general, whenever an organization adopts any new technology, methodology, or approach, that adoption has to be driven by a business need. Any kind of system that need rapid delivery of innovation requires DevOps (development and operations). Why? DevOps requires mechanisms to get fast feedback from all the stakeholders in the software application that's being delivered. DevOps approaches to reduce waste and rework and to shift resources to higher-value activities. DevOps aims to deliver value (of organization or project) faster and more efficiently. DevOps Capabilities The capabilities that make up DevOps are a broad set that span the software delivery life cycle. The following picture is a reference architecture which provides a template of a proven solution by using a set of preferred methods and capabilities. My Remarks Okay, that sounds cool. What does it simply mean, again? The f...

How can you design the software which is built in tiny increments? How can you ensure that the software has a good structure which is flexible, maintainable and reusable? ARE'NT YOU GOING TO MISS THE BIG PICTURE? Not really! In an agile team, the big picture evolves along with the software. How? With each iteration, the team improves the design of the system so that it is as good as it can be for the system as it is now. They focus on the current structure of the system, making it as good as it can be . How do we know if the design of software is good? Avoiding these following  symptoms of poor design (design smells) should be a way. 1. Rigidity - The design is hard to change. 2. Fragility - The design is easy to break. 3. Immobility - The design is hard to reuse. 4. Viscosity - It is hard to do the right thing. 5. Needless Complexity - Overdesign 6. Needless Repetition - Mouse abuse 7. Opacity - Disorganized expression These symptoms are similar in nature ...

I n my point of view, if a team has a good collaboration, team members will achieve the following: To be more effective To make work more enjoyable I have been working for a company for nearly four years as an software developer. Working on various projects from maintaining existing systems to developing a substantial product resulted in me moving to new teams three times. Actually, my most stable team lasted only around three years.  Every time I've moved to a new team, I have a chance to work with new members and a new team culture again. Indeed, I realize that there is a process of developing the team collaboration which gets better time by time. I think it is an evolution ! Phase 1: Poorly collaborate For example, that is when the team members have the following issues: Only work on his/her area of expertise Don't communicate to others Be not confident to take on new challages Don't listen to other members. Subsequently, the team ha...

If you do Scrum at work, you might be very familiar to the estimation in Planning 1 . My PO has once complained to my team that why it took too long for estimating just a story. Wasting time results in the planning timebox is violated. I give you some advice from my experience: Estimation is estimation, not measure. When you read some requirements, you see some risks but you actually don't know how complicated it will be.  Don't try to influence the others by explaining how to do it in too detail. Just keep in mind that you know the business domain pertaining to customer needs and estimate how much effort you will spend for it. The effort should be compared to your baseline one that you use for a simple requirement. The bottom line is we do "relative estimation", not absolute estimation. For example, you are asked to estimate the height of a building. Basically, you just need to answer "how many times higher is the build than your height"; you do...

User Story is the place PO gives his ideas about features so that developers are able to know what requirements are. Acceptance tests are these show the most valuable things of the features represented by some specific cases. Usually PO defines them, but not always. Therefore, refining existing acceptance tests – even defining new ones that cover all features of the User Story must be a worth task. Acceptance test with Given When Then pattern If we understand what we are going to do, we can complete it by 50% I have worked with some members those just start implementing the features one by one and from top to down of the User Story description. Be honest, I am the one used to be. What a risky approach! Because it might meet a case that is very easy to miss requirements or needs to re-work after finding any misunderstood things. I have also worked with some members those accept spending a long time to clarify the User Story. Reading carefully of whole User Story by defining...

Have you ever got bored with the Retrospective meeting? I have, sometime. Most of the times, this meeting just goes traditionally by answering three questions: "What good things have we done? What bad things have we done? And, what actions should we improve?" Ever and ever again! My team found a way to make it a little bit more exciting. The idea is that each member - not only our Scrum Master - will become a host. If a meeting is hosted by a memeber, the next meeting will be hold by another one. Yeah, I used "Sailboat" pattern in my turn. So, I just want to share with you guys how it was. I started the meeting by telling a short story that I hoped everyone in my team could recall the meaning behind of Retrospective meetings: There is a group of people trying pick up trash in a park. At the first look, the park seem not to have a lot of trash because they are spread out all over the place. However, these people continuously found trash when they sta...

This article is available at blog.scrum.org , here I just quote my favorite points and give my comment at the end of this post. Ken Schwaber and Jeff Sutherland, the creators of Scrum delivered a webinar on their latest update to the Scrum Guide .  The update was a simple one, adding the 5 values of Scrum to the Guide: These values sound easy? Well, there are many misunderstandings and common problems when applying these values. Here are some example: Value Misunderstanding Getting the value right Commitment Committing to something that you don’t understand because you are told to by your boss. Committing yourself to the team and Sprint Goal. Focus Focusing on keeping the customer happy Being focused on the sprint and its goal. Openness Telling everyone everything about all your work Highlighting when you have challenges and problems that are stopping you from success Respect Thinking you are helping the team by being a hero Helping peop...

"Names are everywhere in software". "The hardest thing about choosing good names is that it requires good descriptive skills"[1] . In my previous post, I emphasized that we should take care our code , so now let's start with naming. Issue Original code Revised code Reveals nothing int d; //elapsed time in days int elapsedTimeInDays; Difficult to understand public List<Cell> getThem() public List<Cell> getFlaggedCells() Specific to programmers accountList accounts Number-series public void copyChars( char a1[], char a2[]) public void copyChars( char source[], char destination[]) Noise words (indistinguishable) customerInfo vs customer; accountData vs account customer, account //distinguish names in such a way that the reader knows what the differences offer ...