Project Management

Methodology / design pattern / development driven apa yang paling bagus?

Saat sedang melihat-lihat group programming di facebook, saya pernah melihat beberapa job opportunity dengan slogan seperti berikut: “Perusahaan kami menerapkan agile dan scrum!”. Banyak juga bahasan mengenai “agile” lebih baik dari waterfall, adalah metodologi terbaik. Tidak sedikit pula junior programmer atau analyst atau project manager baru di kantor-kantor yang bersikukuh bahwa team harus mulai menerapkan agile dan scrum. Hal yang sama juga berlaku pada TDD (Test Driven Development). Benarkah scrum + TDD adalah metodologi yang terbaik?

Sebelum saya melanjutkan dengan pembahasan yang lebih detail, akan menekankan hal yang menurut saya pribadi paling penting dalam pengembangan applikasi / system:

Pergunakan tools / cara apapun yang dirasa terbaik untuk menghasilkan applikasi yang bekerja dengan baik, dan mudah diubah. “Make it works, and changeable!”

Individuals and interactions over processes and tools

Salah satu manifesto yang cukup penting dan sering dilupakan dalam agile adalah “individuals and interactions over processes and tools“, atau bisa disingkat sebagai “people over process“. Sebagai programmer / developer / analyst, terkecuali kamu adalah ConcernedApe yang men-develop indie game “Stardew Valley”seorang diri dulunya, kamu akan bekerja dalam team, berinteraksi dan membuat keputusan-keputusan bersama.

Preferensi setiap orang berbeda-beda, dan metolodogi tertentu bisa bekerja di satu kelompok orang, bisa juga tidak berfungsi di kelompok orang lainnya. Bagaimana kamu dan team developer bisa bekerja dengan baik adalah yang terpenting, proses / metodologi adalah “alat bantu” yang bisa digunakan untuk mencapainya. “Scrum user story“, “Kanban board” tidak lebih dari hanya alat bantu untuk bekerja dalam team.

Bila dalam beberapa situasi tools tersebut tidak dapat digunakan dalam team, misalnya mayoritas tidak mengerti cara pakainya, atau tidak merasa ada manfaatnya, atau misalnya projectnya cukup kecil sehingga tidak diperlukan, maka carilah alternatif tools yang lebih dapat bermanfaat bagi team. Misalnya post-it notes di cubicle kerja masing-masing, atau minutes of meeting yang di-share dalam email, atau bug tracker.

Pernah saya berdiskusi dengan seorang project manager yang cukup berpengalaman, mengapa beliau tidak menerapkan daily standup meeting, yang umumnya adalah senjata pemungkas di scrum. Beliau menjelaskan bahwa teamnya bekerja secara remote di berbagai daerah yang berbeda, sehingga daily standup meeting tidak dapat dilakukan. Selain itu, tidak selalu ada hal yang dapat di-share dalam daily meeting, sehingga beliau menerapkan rule weekly report, dan contact langsung apabila ada (laptop, mouse rusak misal atau approval) yang diperlukan. Itu adalah contoh “people over process“.

Management juga tidak akan serta merta mengubah metodologi yang sedang berjalan secara tiba-tiba, untuk mengadopsi scrum secara mendadak. Perubahan itu terlalu beresiko, apabila team tidak terbiasa dan banyak yang tidak mengerti, maka perubahan hanya akan membawa musibah daripada manfaat. Terkecuali memang ada kebutuhan untuk meningkatkan metodologi development, jangan memaksa management untuk berubah demi ego sendiri atau “hanya karena scrum lebih baik”.

Metodologi sebaik apapun tidak akan berguna bila team tidak dapat menghasilkan applikasi yang berfungsi dengan baik

Scale it!

Salah satu hal yang menarik yang saya cermati adalah tidak banyak orang yang menyadari bahwa metodologi yang berbeda bisa diterapkan dalam skala yang berbeda pula, dalam satu organisasi. Misalnya project manager dan customer menggunakan iterative waterfall untuk memecah-mecah feature development ke dalam project-project, sebagai team bisa saja development dilakukan secara agile / scrum.

Atau hingga dalam skala personal sebagai programmer, kamu bisa saja memecah task list yang diberikan menjadi iterasi2 yang bisa menghasilkan feedback dalam 2 minggu (iterasi standar scrum), dan melaporkannya ke project manager / team lead secepatnya.

Don’t forget to make it changeable!

Saya berani bertaruh, tidak ada development plan / requirement yang tidak berubah saat development. Perubahan requirement adalah sangat wajar dan sangat mungkin terjadi. Di luar negosiasi finansial yang memang bukan ranah developer, mengembangkan applikasi agar bisa mudah diubah-ubah sesuai dengan perubahan requirement adalah penting. Applikasi yang mudah diubah juga penting agar dapat menambahkan fitur dengan mudah di kemudian hari. Hal ini juga tersirat dalam agile manifesto, “Responding to change over following a plan“.

Lalu bagaimana dapat mengembangkan applikasi yang mudah dikembangkan / diubah? Salah satunya adalah dengan membuat “low coupling, high cohesion” modul (class / function). Dan TDD dapat membantu mengembangkan kode yang low coupling tersebut. Namun dengan efek samping development time yang meningkat hingga 2x dari biasa dan kompleksitas dalam unit test, tidak semua team dapat menggunakan TDD (namun pastikan menggunakan TDD bila memungkinkan).

Ada 2 pemahaman lain yang juga dapat membantu mengembangkan kode “low coupling high cohesion”, yaitu Single Responsibility Principle, dan Dependency Injection. Keduanya adalah bagian dari SOLID principle, yang menurut saya lebih bermanfaat dari ke-3 pemahaman lain dari SOLID principle.

Conclusion

Pergunakan development method yang paling cocok dan bermanfaat untuk team. Kembangkan applikasi yang berfungsi, bisa digunakan dan mudah untuk diubah. Kembangkan kode yang “Low coupling High cohesion” agar applikasi dapat diubah dengan lebih mudah.

Advertisements

Quality : Project Manager – Decision Maker

This is an extended / deep down session for Quality : Project Manager series.

Decision Maker, why a project manager (or to be precise, all manager) need it. This session applied to almost all manager-level, while in this article, I write project manager as representation.

Most of the time, a project manager must lead their subordinates to face problems and tasks. There are almost infinite solutions that can be taken to do those problems and tasks. A project manager must make decisions about those solutions and choose the best one. Making a good decisions is another discussion and problem out there, able to make one or not at all is the problem here.

An indecisive manager is bad manager. If in your company have manager with this quality, fire them immediately. They bring more harm than good.

A decision, after being made by the manager, will be executed by the staff or his/her subordinates. Now if the manager does not make the decision, what can go wrong?

The Decision Making Will be Done at Lower Level

The lower level I mean here is supervisor level or even staff level. I can imagine that almost all the time, those indecisive manager will only order their subordinates to solve the problem, without giving directions or clear instruction for those orders.

Those unclear instructions will resulting in more decisions that their subordinates must make. More indecisive the manager and unclear the order is, the more decisions that the subordinate must make. Then what? Is it bad? Before I continue, I want to emphasize that when the decision is made at supervisor / staff level, the decision will be split into smaller decisions, and more people that will make the decisions.

More People Making Decision = More Unaligned the Overall Action

Let’s say that we have a naval ship, frigate class (well, I like the Golden Age of Piracy theme) with 80 crews, one captain and 10 masters (supervisor levels). The captain is given a task to exterminate the notorious pirates at Tortuga (Pirates of Carribean, ahoy!). He will set sail from Port Royal.

Imagine that the captain say to the sailing master (navigator) and other masters like this: “we need to exterminate the pirates at Tortuga”. How will the masters do their job? Each of them will have different plans in mind. For example: the boatswine want to direct the ship 100 km (~62 miles) from Tortuga for restocking, while the quartermaster want the ship to port nearer to Tortuga so they can gain information about said pirates, and sailing master now begin to wonder whether the weather is good for sailing.

It will be worse if the sailing master said this to the navigation crew: “we will go to Tortuga to exterminate some pirates”. Among dozens of sailor crews, there will be some that want to sail to the west, and some to the northwest, and they won’t make much progress.

What is the Result from Unaligned Action

Now that the crews are confused. That can resulted in delayed actions due to need of plan reconciliation between masters and crews. That delayed actions costs supply, money, and threaten the mission. It will be worse later when the preparation is not good, the supply is badly managed, they run into bad weathers, they are ambushed by pirates in the trip, etc. That can costs them live and the success rate for mission is significantly lower.

What if?

Now only if the captain said something like this: “We need to exterminate pirates at Tortuga. in one week, we will set sail to port X, 100 km (~62 miles) from Tortuga. We will take the northwest route, a safest one that passed Y bay. We want to minimize the encounter with pirate during the trip. From there, after 3 days of resupply, we will continue to move to port K, 5 km (~3 miles) from Tortuga. We will use one week for resupply, learn the weather, topography and gathering information about the pirates. Then after deciding which attacking strategy we will use, we attack them”.

We can see from the second instruction that the captain give very clear instruction to the crews. Now the crews know what they need to do and each master can make plans to support the original plans made by captain. Immediately after, they can discuss between each other master about the more in-depth technical plan, then later being completed as masterplan, that will be used as guidance for the mission. Each masters can handle their own team and each teams can act according to plan. The success rate for mission is significantly higher.

The same decision is also needed when encounter with emergency situation, such as sudden bad weather and ambushed by pirates. If the captain is indecisive with his decision, the entire crew will be in chaos.

Conclusion

Indecisive manager can threaten the success rate of a task / mission. Usually even though the task is completed, it will costs more time and financially as well. A clear decision and instruction will resulting in more responsive subordinate and increasing mission success rate. As a note, a manager that like to change decision that his/her has made is not different that the indecisive one. The master plan that has been discussed before can change, resulting in extra cost for subordinates to re-align with the new plan.

Quality : Project Manager

This will become a first part of Quality series, a series where I will talk about quality about something (in information technology world) from my point of view. I try to be as objective as I can but cannot denied that this series will have many subjective aspects from me.

Now I’d like to talk about quality of a project manager.

Long story short, I have worked under some project managers. However I only have worked with 2 project managers for a long time, and the others are short-terms. The last and current project manager that I’ve worked with for a long term is Mr. Ivan Kristanto (well, his name is better in English). He is the one that makes me want to discuss about a quality of project manager. And within my qualification, he is a good one in my opinion.

Let’s see what can my point of view details about the quality of a project manager.

Decision Maker

They need to make decisions for many aspects. If they are inconsistent / indecisive, it will only bring troubles for their subordinates.

Good Communicator

Hey need to communicate their plan, strategy and design. To do so they need to have a good communication skill so they can describe those things very well and their subordinates can understand what they mean.

Technical Knowledge

If the company has a solutions architect, this criteria placed for them. However most of the time, project manager is also same with solutions architect itself.

A project manager need to know the current technology and their technical use. The technical knowledge needed to be possessed by project manager does not means the deep down technical details that programmers know. It should only be about the general technical knowledge like web services, batch processing, scheduled job, etc. With these knowledge in their hands, they can decide which approach / design that will be the best for the system.

Projects Knowledge

A project manager is responsible about the project that they are taking charge. They not need to understand the project deep down to technical programming details, It is more into the business flows and rules.Because they are responsible to make plans for changing the project, they need to know what impact will be happen when the change request being applied, is it compatible with the current process, will there need any data conversion, etc. When things get out of control from original planning, the project manager will always be one who will be asked for help. If they don’t know the flow of project deep down, all of us are gonna get into trouble.

Workforce Knowledge

Project managers should know how good their workforce are. With knowing how good their workforce, they can make more accurate plans and schedule. They can also know whether one task can be done with their workforce or not. As well as the quality delivered.

Test Supervisor

In order to ensure a change will break or cause problem in other places, the change should be tested. Usually, there should be several test cases that must be passed to ensure the quality of the change. The responsibility for whether a change will cause problem or break is placed on project manager, so it is logical if the responsible to supervise or review the test results are held by project manager.

Scheduling Ability

They need to make yearly planning and milestones. If things go south, usually they need to re-adjust some of the plan so that the change will not become very different with current plan. Without this ability, the company cannot decide clear goals and at the same time will bring much overworks onto the developer.

Budgeting Ability

I don’t know much about how important for a project manager to manage budget. However, as we all know, they are responsible to handle the upcoming projects, workforce and timeline, as well as the hardware and licenses required. So a direct requirement or not, a project manager will need budgeting ability as well.

Conclusion

Rather than having strong technical skill at computer programming, they need more abilities at the soft side and management skill, while still maintaining their general knowledge about technology. Moreover they also need to understand which projects that they are responsible to, and understand the flow of it.