Debasish: Is there a distinction between what Essence is and what a kernel is?Ещё он вновь разъясняет, почему эти чеклисты именно про альфы, а не про рабочие продукты. Это про результат содержательный, а не результат по форме (увы, нам часто не удаётся объяснить менеджерам и инженерам: все привыкли к внешнему контролю по форме, а о внутреннем контроле по содержанию даже не хотят задумываться):
Ivar: Yes. Essence is a kernel for software development endeavors. Thus, Essence is a specifi c kernel. There could be other kernels.
Pinakpani: What might be a difference between one kernel and another?
Ivar: As I just said, Essence is a kernel to support endeavors that result in a software system. There will be an extended kernel for systems including hardware and peopleware – a kernel for systems engineering. So there could be other kernels. Now what we have seen is the Essence kernel developed for software endeavors can be easily modified to also work for system engineering. So Essence is inherently more generic, but we now want to focus on software to make sure the kernel is efficient for software development.
Debasish: So could I say in the most abstract sense, a kernel attempts to establish a common ground for a group endeavor, and that group endeavor could be anything. In this case its software, but it could be building a skyscraper or building a bridge or building a company or anything like that. Correct?
Ivar: Yes, in Russia people have realized that a kernel similar to the Essence kernel could work for almost any human endeavor. As a first example, a team in Russia coming from the Russian Chapter of INCOSE is working on extending the Essence kernel so that it also includes systems engineering – hardware and software and people ware. The changes to get there are rather small.
Pinakpani: You often talk about software project checklist. Checklists have been around forever and ever and not given a value expected. What are these and how do they help a software professional? A developer, a tester, an architect or a project manager? Why do you think your checklists are better?Ещё один горячий пункт, это про размытость и невнятность формулировок вопросов в чеклистах Essence. Это сделано намеренно, но именно это в Essence дико раздражает "железных" инженеров, именно в нетерпении к этому и в непонимании этому самая существенная разница между культурой программных и железных инженеров (по крайней мере, железных инженеров советской производственной системы). Железные инженеры хотят в этой части взять под козырёк, но не хотят ничего обсуждать -- "как начальники прикажут, так мы и будем делать. И вся ответственность на предложившем вопросы. Сами же ни о чём договариваться не будем -- о чём там договариваться? Всё и так ясно". А основная идея Essence -- это как раз договориться внутри команды! И не отделываться "готовностью рабочих продуктов", и не обманываться, что "и так ясно". Вот:
Ivar: Historically we have used checklists to identify progress. The problem with these checklists has been that they have usually been related to the fact that you have done a particular activity or that you have written a particular work product, a document or something like that. Such checklists are very easy to cheat and not really very useful. The fact that you have written a document doesn't mean the document is valuable. By having states representing real outcome, you know you really have achieved something when you have reached a particular state. And not in terms of written documents or performed activities. For example, the Team Collaborating state cannot be achieved just by listing the names of your team members. It requires that the team members are communicating in an open and honest way, and that the team members are focused on their agreed mission. That is actually the key to the difference. Our checklists are measuring or identifying that you really have achieved something and not that you have filled in a document template or that you have performed an activity.
Debasish: So are you saying that the particular kinds of checklists that you've got are trying to measure the quality of the item or activity or artifact?
Ivar: Not exactly. Essence doesn't care about documents at all, it doesn't care that you have done some activity. Instead, Essence cares that you have achieved something of value like executable code. Executable code is a real result. For instance, that you have written a requirement specification is not something that we would use to measure progress. Instead that you have got consensus among the stakeholders that these are the requirements for what the system is required to do.
Pinakpani: The different checks in the checklists are ambiguous. What value does such checklists give?Тем, кто дочитал до этого места, будет интересно и замечание Ivar про постепенно восстанавливающийся после воцарения agility вкус к архитектурной работе:
Ivar: That is really a very important question. If you go through a checklist for a particular state, it's not necessarily instantly clear what is meant to achieve a state. This is actually intentional. If we tried to make it unambiguous, we would have to express ourselves in a formal way and then almost nobody would understand what is meant. On the other hand if we had no precision at all the checklists wouldn’t give us any hint of the meaning and that wouldn’t make them useful. Let's go back to the Bounded state we discussed earlier and look at the example checklist item in this state that says, “the stakeholders have a shared understanding of the extent of the proposed solution”. Some people might think we need a complete and consistent set of requirements that are frozen to achieve this state but that is not what is meant by Bounded. A “shared understanding of the extent” means the stakeholders agree where the boundaries of the proposed system lie. The team needs to agree that this checklist item is achieved by discussing it within the context of their own endeavor. This is one of the reasons we refer to Essence as a “thinking framework.” Instead we have had to strike a balance and to some extent rely on people’s experience. We know that within a team, people may have different opinions about the meaning of a particular checklist item. That results in a discussion, which is most valuable, and eventually the team will decide on how they interpret the checklist item and take a decision about whether the item has been achieved or not as in the example referred to previously.
Debasish: In one of your prior answers you used the word "consensus" – for example, is their consensus about the requirements. The ambiguous word there is obviously "consensus". Does consensus mean 80% of the people like it or my boss likes it? What is the meaning of "consensus" is partly environmentally determined. That makes it a useful ambiguity. It makes it a useful ambiguity because it brings up discussion which inevitably must be clarifying to the process. Would you agree?
Ivar: Yes, exactly that's a very good example. It brings up a discussion and the team will eventually agree and take a decision about whether we have achieved what the checklist item implies and whether we have consensus or not.
Pinakpani: The ambiguity brings up a discussion of a likely critical aspect of the endeavor as opposed to that being left out of the mind of the developers. Or everybody assuming things are okay without really having had an explicit agreement. Would that be a fair statement?
Ivar: Yes.
Debasish: Object orientation and component based development stood on strong philosophy of separation of concerns and compartmentalization of responsibilities. But, immature learning as well as lack of fundamentals often leads to poor conceptualization of code reuse. If code is not usable in its first instance re-usability is a far cry. Do you agree?
Ivar: Software reuse is a complex area and much can be said about it. Together with Martin Griss, I wrote a book (Software Reuse…), which discusses the questions you raise. Briefly, I would like to say that software reuse is something you need to architect to get. It is not something you get for free. It requires architecting competencies that have not been promoted since the world became agile. However, architecture practices are on its way back and software reuse will once again be a concern for all IT executives.