Making Requirements Stable

Building custom solution for a customer is challenging. The most challenging part in building custom solution is change requirements. We already know, there is no stable requirements. Every requirement that customer said can be replaced, changed, or added. In requirements engineering, a way to make requirements stable is by doing requirements managements. In this article, we will discuss what requirements management is and how to make sure it can be worked in the requirements that we already developed. Requirements Management Requirement management is part of requirement engineering. As we know, requirement management consists of two components. The first one is requirement development as a technique to obtain requirements. The second one is requirement management a way to make sure the requirements can fulfill expectation without sacrificing the development teams. The detail of requirement management can be read here What is Requirements Management | IBM Although the principle is similar, requirement management can be different in Agile environment. In Agile environment, the requirement management is not structured as in the formal one. The product owner or product manager should handle the requirements management in daily basis. There are several principles that will be adopted in Agile environment. medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299"; There is always 'version zero'. The user story should have version zero. Initial version that will be modified and changes. The team should discuss with the customer for the initial version of user story. There should be regular meeting with the customer on each iteration. The regular meeting should be happened at least weekly. There should be a proof of concept (POC). The POC can be viewed by the customer to validate the requirements. Ideally the POC should be sent after a week of regular meeting. The customer can say go or not go based on the POC. There should be acceptance test that can be tested based the tester or customer to validate the requirements. There should be unit test for the user story that 'complex' enough to validate and can be done automatically. There should be a versioning of the user story. This is to make sure changes is documented and logged. Requirements Changes does not mean it should change! In agile environment, it is said that the requirements will be changed, and you should manage it. I recommend you to read Agile Requirements Change Management ( And here are the quick tips. When changes happen, do a discussion with the team. What the impact of the changes. When there is an impact, there will be additional work of solution. On this stage, choose which solution that can be done by the team with two considerations. Perfection of offered solution. Least of work solution The development team chooses which offer that will be given to the customer. The product owner / product manager will tell the customer about the changes and the 'additional' work and budget. If the customer agrees, the product owner will add the changes of the user story into the next iteration / sprint.   medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

How Agile implemented in DevOps

Agile is a current software process that is believed to be a solution to build a software. On this article, we discuss how to build a software that implemented Agile and DevOps. For the real example, we will use azure DevOps and eXtreme Programming (XP). Let us get started: #1 Creating a DevOps project After the project is agreed and the contract is raised, the team can start to create a DevOps project. They should do: Choose the process template (in this case we choose Agile). You can learn step by step here Create a project - Azure DevOps | Microsoft Docs Invite your development teams, product owner, and others stakeholder. Set the iteration path. You can learn step by step here Define iteration paths and configure team iterations - Azure Boards | Microsoft Docs Preparing the development environment. You can deploy the development infrastructure in Azure and connecting to your DevOps. You can connect by using service hooks. You use Azure Service Manager if you connect with Azure Subscription that SAME with your Active Directory. You use Azure Classic if you connect with Azure Subscription that different with your Azure Active Directory. You can use Terraform If you want to publish your solution to Amazon AWS. Creating initial project with Visual Studio and push it into GitHub or Azure DevOps. medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299"; #2 Composing the user stories. This step is a casual XP based requirement engineering technique. Creating features, Defining the actor or persona Creating user stories, Creating iteration plan with user stories deliverables Discussing the features, user story, and iteration plan with the customer #3 Designing the Solution. You start this step by creating a mockup for your design. You can start with. Creating information architecture (IA). You can create the IA with Mindmap software such as MindManager or XMind. Create low fidelity prototype. You cab create with your pencil & paper or user wireframe tool like PowerPoint or Balsamiq. Discussing the low fidelity and IA with the customer Creating high fidelity with Visual Studio or Visual Studio Codes. Uploading and presenting the High-fidelity prototype to customer #4 Developing the Solution. This step can be the longest step in the project. This is because the solution is developed through one or more of iteration. Of course, this step is executed iteratively. Since we are using XP, the development team (tester) should create a test suite, test plan, and test case. You can see the video here The developer should create unit test in Visual Studio. The developer should create the codes to fulfill the user story. The developer will commit and check-in daily to the repositories. The CI/CD process will deliver the nightly build. The iteration review will be happened in two stages. Internal play testing – with the development team. Customer play testing – with the costumer Revising and getting feedback from the customer or from the defect. Iteration retrospective with the development team and others. It discusses how to improve the next iteration of the development such as: How we communicate with the customer What we need to change in the next iteration How the development progress so far Deploying the solution for the iteration. Continuing to the other iteration #5 Implementing the solution. After the entire iteration is finished, it is a good time to implement and to finish the solution. Confirming the customer that the solution is appropriate to be deployed. After the confirmation, the development team can create documentation such as: User manual Developer manual (optional) Doing several workshops to socialize the system. Gathering the feedback for continuous improvement. Ready for the next improvement and for the next project. medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Release planning session

So our business analyst ready to kick off a project. the real question is what should we do in release planning session. A session where we start the project for the first time. On this article, we will discuss the main activity in release planning. the activities follow the eXtreme Programming method. Let's get started Writing Story The business analyst should write user story as comprehensive as possible. the business analyst will create set features. i.e. Registration Feature  user story  i.e. as a member i can register through social media account so that i dont need to fill basic information  acceptance criteria i.e. member should have at least first name, last name, organization, and email  Estimate the Story The business analyst should elaborate with the customer to do several things Validating the user story with the customer Detailing the user story and acceptance criteria with the customer Estimating the story point with the development team  Creating the release plan The business analyst will do several activity to make the plan is solid Discussing the story depedency with the developer Discussing the story priority with the customer Creating iteration plan that contain user story Stabilzing the release plan The business analyst should understand that the story will be changed. Therefore, the business analyst should stabilising the plan by doing several activities iteration review with the customer / weekly progress with the customer documenting feedback based on the review  reviewieng the changes into updated story  discussing the detail of the story with the task with software development team   medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Mob, Pair, or Solo Programming

Programming is a challenging task. You need to focus, to solve a problem, and to create a solution for problem. There are so many ways to do programming. In Agile environment, programming can be done through three ways. Solo programming, Pair Programming, and Mob Programming. This article will discuss when you choose one compare to the others. Solo (all in one) This is just like a song from Katty Perry featuring Clean Bandit. Solo! Solo means you do by yourself. You did plan, do, codes, and test activities. The solo great when Project is simple and less complexity. Less external dependencies and stakeholders. Limited user experience Benefits of solo programming are: Faster in development Codes are understandable. Easy to manage. Challenge in solo programming is: Limited design principles applied during the development process. Exhausted and bored Undocumented codes You can learn more here The Personal Software Process (PSP) ( medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299"; Pair (~2 developers in same role) Pair is a couple way to do programming activity. Pair programming is great when. Pair is available with different skills and knowledge. Pair is great when face-to-face communication. Pair is great when we have same role in a team. Benefits of pair programming are: Well-design product two head is better than one. Transfer knowledge happens. Shared ownership of the codes. The pair knows the codes. Challenge in pair programming is: Slow down the productivity. Hard to implement in distributed environments (e.g., different time zones) Suitability of pair person. You can learn more about pair programming here On Pair Programming ( Mob (> 2 members in different role) Mob is more than two peoples work together. Mob is great when. Having members with different skillset Having a good workspace to work together. Having a jell team with good communication model. Benefits of mob programming Project understandability is the highest among the team members. Validation and verification happen between members. Near real time feedback model to shape the well-designed project Challenge in mob programming Specific infrastructure is needed. The communication between members should be fluid between team members. Limited productivity when the others work while the others only see the process. You can learn mob programming here Mob Programming Basics – Mob Programming So which one you prefer as your programming style? Put a comment please.     medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

The Simplicity in User Manual

User manual is still needed. However, it should as simple as possible. The real question is, what the content of user manual that can be as simple as possible and provide simplicity guide for the user. This article will guide it for you. If you are Scrum or XP user, this agile user manual is for you. This is the improvement of my previous post Creating Agile User Manual ( What you Put in Your Manual Technically not everything on the DevOps work item. You can put the essential information such as Product vision, mission, and success criteria Product version and history Product actor. Who will use the product? Product feature. List of features Product user story Product guide how to use the user story. User story limitation and rules medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Creating modern user manual with Snagit 2021

Why your Customer does not read your user manual? If you still wondering why the user manual is never read by the customer, or why your customer still asks to you although you already have the user manual. this article is for you. On this article, we discuss a new way to create user manual by using SnagIt. Snagit is more than Screenshot application. it helps you to create screenshot for your manual, create a step by step video, or event simple vlogging to introduce yourself. Today, we have a mission to create modern user manual with Snagit. Snagit can help you to create more appealing user manual in order to increase the user awareness. Of course, building fancy user manual is not solve the entire problem since we also need to create agile user manual. This article is second article from our first article "Creating Agile Manual". If you don't know what Agile user manual is and why you should care, you can visit the previous post. So, what is the characteristic of Agile user manual is? Providing the user multimodal communication. i.e. the user can read the manual, view the visual illustration, or see the video to finish the task. Providing interaction. i.e. the user can comment and ask you about the specific topic regarding the user guide Available online. The modern user manual should be accessed through online through web. medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299"; How Snagit can help? Snagit can help you to create better look and feel in your agile user manual by providing some of key features such as: Providing you multimodal recording Snagit 2021 can help you to record Onscreen video with better compression and quality ratio. This is the most feature that I love so much. Comparing with the other screen recording software, Snagit is clearly the winner of the compression vs quality. It provides you low size video without compromising the quality. Screenshot. You can record screenshot just like the casual print screen. However, Snagit provides you a better way to screenshot anything that cannot see in the screen, such as your scrolled content. As a web developer of Single Page Application, Snagit 2021 will help me to screenshot the whole web page. Creating gif video. If you want to record the video with less than 30 seconds, you can export the video to 'tiny size' animation. Providing you a getting started template to create your manual In Snagit 2021, Snagit Editor provides you a ready to use template to create the user manual. You can choose from the basic 2 steps, 3 steps, till 5 steps. What a good in Snagit 2021 template is: Built in usability in mind. The template guides you to create Agile user manual in usability and avoid 'overload information' Supporting real world scenario such as User manual Request for changes (before and after) User interface explanation (for poster and quick guide) Enriching visual cue in your User Manual In the past, I should create a manual shape and put a number on it. Snagit 2021 provides you more than a shape. For example, my favorite one is a Step. Step provides you a visual cue for your manual. It makes your user manual is better. You just need click your mouse and the label will be automatically assigned. Reusing and Managing the Information If you are creating a user manual for more than one customer, you face situation when you need to do screenshot similar steps (i.e. login to Azure portal). With Snagit 2021, you can manage your reusable library and tag it with useful keyword. You can change the view from Capture to Library and you can reuse your existing slide. The library give you a good classification for your previous capture such as images, video, or animation gif. And of course you can search with your tags (i.e. Azure) Sharing to the others App After using the Snagit, you can share the content to make you more productive such as. Sharing the content to your google drive so you can insert it into a blogger-based site. Sharing the content to SharePoint or Slack to get a feedback from your teammate Sharing the content to Camtasia so you can edit the video Snagit support major application that might need to use it That's it! Let me know if you need detail tutorial about how to use Snagit in Bahasa Indonesia! medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Creating Agile User Manual

The challenges with our user manual User manual is something that is sometimes forgotten. Even though we know that a person's understanding of one system is different from another. We sometime neglect the benefit of user manual for sharing knowledge between the development team with the end-users. The challenges of the current user manual is: Video user manual – visually rich! Slow on update. Making a video for user manual is great, but the effort to create a video for something that 'constantly' changes is huge. (-) There is a lot of effort to design, create, render, and share the video. (-) Hard to find the specific information if you do not split your video or indexing it (-) Document user manual – completed and easy to maintain! the user does not read your document. They only receive as part of your invoice. (-) Some users are too busy to read the user manual. They tend to learn the application through learning by doing (-) The demonstration is though through document, you should do a lot screenshot for your document (-) In app user manual - interactive and integrated with your app! The user manual is not easy to update since it should follow the build rules in the application (-) The user manual is separated in several menus, sometimes it hard to maintain (-) In app user manual needs extra effort in development side. Context based, wizard, tool tips adds the task for development team (-) The Agile User Manual Agile user manual is an initiative to make user manual as a live document with several principles Easier to deploy and to update Providing quick problem-solution Rich in content you can put video, document, or even tweet from your company update The idea of agile user manual is providing the user live document with better usability and access. medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299"; How to create Agile User Manual This is an example how the agile user manual is created Choosing the 'live' platform that can be shared to your users. For example, we are using Microsoft Sway as our 'live' platform Choosing the easy to use video creation platform for your screensharing. For example, we are using Techsmith Snagit 2021 The steps that we can do is Create a Sway document with your company account (not the personal one) Share the sway document with the others development teams Create a layout. Each layout is a slide for certain functionality Create a short video with Snagit. You can create less than three-minute videos for delivering the functionality of your application bases on a layout Put the short video into the sway document Share the Sway document to your customer You can see the tutorial in the next post. Enjoy! medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

Understanding Features, Stories, and Tasks on Visual Studio Online

When developing a software, you might think what is the better way to acquire the requirements. If you learn software engineering you might be remember about software requirements or requirement engineering. It is a long journey to learn about requirement engineering. You should read a lot documentation, create requierement template for your client, filling the document and discuss within the client. If you have done already you might be agreed that sometimes the 30 pages requirement page won’t satisfies the client if they change they mind. You put a lot of effort to create the req’ document but in the end is useless when client changes his mind. In this article, I will share you about what you need to know to create better requirement based on my thought on ALM (Application Lifecycle Management) minimalist. Please note, that ALM minimalist is not a formal method like waterfall, but is an Agile technique that simplify the ALM. If you akready use the Visual Studio Online, you might be familiar with Features, Stories, and Tasks on the Work Tab as shown in figure below. In the picture we have features, stories, and tasks. We will describe it in this post each element of that to make your requirement simpler and adapt to change. Starting with Features. If you ever read a good book about FDD (Feature Driven Development), you might be remember about features. Feature is the unit of the “things that it wants by the customer’. In the ALM Minimalist, feature is simple statement that explicit the client need. On the Visual Studio Online, you can add features by clicking the work tab and click the new button. Here are several sample of feature               The simple patterns of Feature is Features = Action + Object Feature should also provides additional information such as Who owns the feature. it means who will responsible with that feature The prioriy of the feature (1 for high priority, 3 for less priority) The iteration when the feature will be develop. In Visual Studio Online, you will get a lot filed to fill by clicking the feature. However, ALM minimalist encourages you to keep it simple by avoiding fields Exploring Features into Stories So you have features, you can break down into stories. For example, if we have a feature called “Managing The Payment of a Course” you might have several stories such as Paying the course using wire transfer Paying the course using credit card Paying the course using invoice from company As you see, story explains the feature more detail based on several constraint and condition based on customer needs. On Agile book such as eXtreme Programming Explained or others, you will find that the user story has a pattern like below User Story = as a (actor) I want to (action) so that (benefit) for example: as a member I want to pay the course by credit card so that I can join the online course right away In Visual Studio Online, you can do that easily by clicking the stories menu. However, if you feel too complex when writing the formula, you can follow the simple statement such as “Paying the course using credit card”. You can make the story unambigous by adding several information such as Work assigned to (Story Owner). it covers who will do the story  Risk (1 high - 3 low) Story Point. Story point is number of estimation that will be done through planning game session Description. It shows the detail of the story. It is just like usage scenario of the story that described using words Storyboard. It shows the flow of the story and the user interface. it uses Powerpoint to create the storyboard Iteration. The iteration shows when the story will be worked by the story owner, Story is a part of feature. Therefore, you can see the story below of a feature on Visual Studio. In the Figure, it is shown that the story name is ‘simple statement’ about the story, and the desriptions uses the “user story format”. You can add the additional information such as data field and detail information on a storyboard Doing the user story action on a task Task is the lowest unit of the work. Task is assigned to an agile member. Task represents the detail of user story. For example if I have story “see the student list”, I might be have 2 tasks such as showing the student list that already paid the course, showing the student that not already paid. If I have 20 story point, each task should be have not more than 20 point. Task is not only about the activity that contains development activity but also others activity such as design, requirements, deployment, and etc. Fortunately, in Visual Studio Online you can create task and assign them with several field such as figure below   Conclusion ALM Minimalist is an agile technique that has a purpose to simplify the requirements engineering activity. it proposes the three main components which are Feature, Story, and Tasks (FST). The FST can be adopted easily on Visual Studio Online using Agile MSF template.  Good Book to Read medianet_width = "600"; medianet_height = "250"; medianet_crid = "858385152"; medianet_versionId = "3111299";

ALM Minimalist

Enterprise inlines the solution within business. It means any action that create a solution should provide values. Values mean productivity, revenue gain, or cost effeciency. Simply said that values related directly with the business. Last month, we should create a software engineering framework based on tight project management and approval model, as fine as minimalist approach. The proposed solution is called ALM minimalist. So how we create an ALM minimalist, here are the steps: We select the starting template. In this step we are using MSF for Agile. MSF for Agile is choosen because the mature is in the middle between Scrum and CMMI We breakdown and make an effor to understand their project management habits. It is including their approval models and validation model We compose the artifact that minimalist enough As a result we get the templates as a follow: Vision and Scope document Functional Specification Document Master Plan Document Project Execution Reporting document Project Delivery Acceptance form Project Closure document That’s it, hope it will help you to compose a minimalist document for ALM purpose

Testing and Kaizen in Agile Development

Recently, Microsoft Pattern and Practices released a good book about testing for continuous delivery with Visual Studio 2012. This book covers an Agile process in terms of testing and continuous improvement of your software by testing it iteratively. As mentioned in their pages This book is aimed at test engineers, managers, developers, and folks interested in understanding the changing world of test. Over the last several years, software testing has changed a great deal. In the past, test plans were on paper, filed away and out of sight. Today they are—or can be with Visual Studio—living documents, as manual and automated tests are integrating into the test workflow supported by the test infrastructure. Today you no longer have to set up physical boxes; instead you can set up and automate virtual environments composed of virtual machines to meet your testing environment needs. With Visual Studio and Team Foundation Server, the pain of dealing with a heterogeneous test infrastructure is reduced, the cost and effectiveness of testing a product is improved, and regression testing becomes cost effective instead of a nightmare. Knowing how to test is important, but understanding how this new infrastructure is changing the business of testing and software delivery is critical. Today's businesses require nimble teams that can support continuous delivery and deal with updates and bugs in an agile fashion. It's what your customers have come to expect. In this guide, we follow a team as they move from a conventional approach to testing towards one more suited to the needs of present-day development. We see how they address the costs and the pain of their old methods by adopting the testing infrastructure of Visual Studio 2012. You can download the book here     Having a good time to learn you can bough a good book about testing and Agile here. Buy one and you never regret it.

Topics Highlights

About @ridife

This blog will be dedicated to integrate a knowledge between academic and industry need in the Software Engineering, DevOps, Cloud Computing and Microsoft 365 platform. Enjoy this blog and let's get in touch in any social media.


Month List