Lerne alles über die Evolution des Ethernet-Standards, strukturierte Verkabelung, Signalisierung und Paketformate.

Download als PDF oder ZIP-Archiv.

Neben vielen anderen Themen werden Dateisystemoperationen, Threads, Netzwerkprogrammierung und SysV-Mechanismen besprochen.

Download & Infos

Download als PDF (5,09 MB, 523 Seiten).
Source Code als XCode Solution herunterladen: ZIP (1,1 MB).

Statistiken
Content: 523 pages, 220942 words, 58 figures, 28 tables, 165 listings
PDF Producer: GPL Ghostscript 8.63
PDF Version: 1.6 (Acrobat 7.x), Fast Web View enabled
File Size: 5,09 MB (5.339.436 Bytes)
Page Size: 8,27 x 11,96 in

Lizenz

Dieses Werk ist unter einem Creative Commons Namensnennung-Keine kommerzielle Nutzung-Keine Bearbeitung 3.0 Deutschland Lizenzvertrag lizenziert. Um die Lizenz anzusehen, gehen Sie bitte zu http://creativecommons.org/licenses/by-nc-nd/3.0/de/ oder schicken Sie einen Brief an Creative Commons, 171 Second Street, Suite 300, San Francisco, California 94105, USA.

Project managers all over the world are sharing the same fate: they feel the pressure of having to add additional value to the product no matter if it is being intended for the public market or specific customer project. Projects are always vulnerable to be chopped for reasons far beyond the project manager’s control. A new breed of PMs have figured out that certain leadership techniques and market insights have a strong impact to the long-term success of any project.

No matter what approaches and methodologies you adhere to, projects are normally managed operationally or strategically and all that matters is the result it brings to the enterprise (or the customer) and to its position in the market. The combination of operational project management and market insights lead to a holistic strategic approach to project management. It focuses on vision, competitive advantage and adaptability, still embracing the methodologies of traditional project management with the right pinch of added value.

At the fundamental level of strategic project leadership is business strategy which needs to be communicated as a project vision to all stakeholders. That way stakeholders understand the project manager’s commitment to the project. Finally, a vision must be transferred into competitive advantage:

1. Project managers are business leaders – Share the responsibility of building business results with project managers, don’t just let them accomplish a task. Let them be part of the business vision.
2. Focus on projects that have the highest potential to contribute to the overall business strategy. Manage the portfolio according to the long-term competitive advantage of the enterprise or the client. Yet, don’t allow projects that are not aligned with the chosen strategy to fall behind.
3. Identify the competitive advantage of every project (or service) in the portfolio and formulate a project strategy in capturing the marketplace. With strategic project leadership there is no single approach for all projects, instead each demands an adaptive and efficient approach.
4. Communicate the project vision and cultivate a project team that believes in the vision’s energy, excitement, and commitment. People have to believe on a sustained, day-to-day basis about their contribution to the project.

Additionally, to increase chances of success of future projects apply conventional techniques to strategic project leadership like creating a hierarchical plan (what I call the SPOT method: Strategy and spirit > Processes and Organization > Tools) and establish effective project monitoring possibly adjusting existing project quality management techniques to the strategic project leadership approach.

Correctly implemented strategic project leadership can be extremely efficient, but remember that it is all about identifying the product’s competitive advantages, marketing this vision to all stakeholders (and the project team as part of the stakeholders) and the overall strategy for delivering the project.

Information itself is almost useless until it is put into context resulting in what we call knowledge. The main problem with information and knowledge is that the latter is result of information processing which is by nature prone to errors. In order to make sense of all that information we construct stories in our mind trying to make logical and causal connections between the “facts”. Missing parts in the causal chain are subconsciously filled in to make sense for us. It is the way our brain works: things have to make sense and if there is not sufficient information we tend to artificially create causality between possibly unrelated scraps of information. Since we do not know if our story is correct but seem to be perfectly sound there is no need to doubt its correctness. Why? Because most information is not verifiable.

Less Is More

Whenever we read the newspaper or listen to some radio shows we automatically start processing the information and weaving a new story or extending an existing one. Consider the following: the elections are over and the news stations start interviewing party leaders who, on the side of the losers, try to explain why they’ve lost the elections. They come up with semi-intelligent arguments about bad campaign strategies, the failure to address the people’s needs and other excuses, yet, only minutes after the election results have been announced these people believe they know the reasons for the outcome. The same is true for the winning party, of course.

Just ask yourself: how do they know? The reasons for winning and losing an election can be manifold: the bad weather kept people away from the voting booths or they just had a change of mind on election day. We just don’t know, and so do the party leaders but they are convinced that they do. You see the problem?

We now enter stage two: the interviewer asks for an expert opinion. The expert explains in great detail why the election went the way it did adding lots of background information to the conglomeration of so called facts. What happens here is that we consume a great amount of completely unverifiable information that may change our perception of things. On the long run we’d be better off without all the noise since the election result is the only verifiable fact that really matters. Consequently, the more information we have accumulated about this particular topic the less precise is the knowledge of events that took place.

We can draw similar conclusions about such dynamics on a variety of topics, when it comes to gossip about celebrities, for example. We are flooded with random noise, useless information that does not add value to our body of knowledge.

We Don’t Know What We Think We Know

Thompson’s article ends prematurely. The most significant part is the where he refers to the Post-Fact Society, a term introduced by Farhad Manjoo, who, in my opinion, correctly concludes that there exists a

disjunction between truth and proof

in an information society. It is important to distinguish between what we actually know and what we think we know. One reason for the illusion of complete knowledge is that we try to examine past events in order to deduce what has happened, again creating a completely plausible story in our mind by connecting the dots of information. It does not matter if we are talking about events that took place hundreds of years or an hour ago. Since we have not been there, we cannot be sure that the information is accurate. We should always remain skeptic must refrain from taking arbitrary information as truth or even proof for our assumptions and theories.

Concluding Remarks

The more information you give someone the more hypotheses and theories they will formulate along the way and the worse off they will be. They see more noise and mistake it for information.

It is almost impossible to protect us from the mechanisms outlined above. It’s far more dangerous to listen to the radio for five hours a day than to read a weekly newspaper since the noise usually is filtered out over time. At least think about the information you’ve consumed today and evaluate it. How much noise did it carry?

Agile principles have become IT best practices [for software development]

said Scott Ambler, agile practice leader for IBM.

Changes

Talking to analysts, consultants, developers and tool makers, I found that the groundswell of interest in agile practices is changing every aspect of how software is produced, from tools and processes to the roles people play in agile organizations.

Three key conclusions emerged from the talks:

1. Going agile is more difficult than many teams anticipate, largely because it turns the roles of project manager, business analyst, programmer and tester on their heads.
2. No two teams apply agile in the same way. That raises questions about what’s agile and what’s not, and more important, whether a process can be improved by adding one or two agile practices.
3. Even though “agile” means different things to different teams, it’s safe to say that agile today is a far less dogmatic development approach than it was in 2001, when the Manifesto for Agile Software Development put Extreme Programming (XP), Scrum and other methodologies on the map.

Written by a group of believers in the ways of agile, the manifesto sums up principles that guide software development, including individuals and interactions over processes and tools and responding to change over following a plan.

Bend the Rules, Please!

One lesson learned from the early agile days is that rigid adherence to a methodology may not work in the real world, said Eclipse Foundation director of the committer community Bjorn Freeman-Benson:

XP is a strict form of agile, and today no one does all the practices. Insisting that the customer do acceptance testing and other things that XP mandates was too large a leap to make.

The customer — in XP, that’s the intended user of the software — was unwilling to take on the time-consuming role XP prescribes. So, rather than bend XP’s rules, the development team canceled the project. A better approach is adapting the methodology to suit the parties involved. A project manager could have assumed the customer role, extracting information from key stakeholders, he said.

Early projects like that gave agile a bad name. Today agile practitioners are more willing to bend the rules. But many are afraid to use the word agile. As a result, there is some stealth adoption of agile going on.

Going wAgile

One way to define agile development is by what it’s not. Some teams turn to agile practices to dig their way out of failing projects by doing two-week iterations, engaging in frequent, intentional communication, and doing frequent builds.

But that’s not agile development. They are simply getting a little bit iterative to put their projects back on track. Often, the line isn’t so easy to draw. Many of the experts I talked to said it’s not uncommon for development managers to add one or two agile practices, such as daily builds and early testing, to their processes. Is that agile? Some teams that take that approach believe it is. But wAagile—that’s traditional waterfall development with a couple of agile practices thrown in—may be a better way to describe such efforts.

A process becomes agile when one practice leads to another practice. For example: You decide to do continuous integration which means a new build is launched each time new code is checked in. That, in turn, impacts how you interact with users, how often those interactions take place, and how you do test cases.

One thing leads to another: You can’t apply just one part of agile without ultimately applying it everywhere.

The trick is choosing a balanced set of practices, but remembering that you don’t have to choose the exact set that Kent Beck (XP’s inventor) chose.

The Eclipse Foundation practices its own agile development approach. Known as the Eclipse Way, it sets guidelines for the 87 projects that fall under the Eclipse umbrella.

Faith Versus Facts

The experts I talked to were quick to weigh in on what’s agile and what’s not. But curiously, the question of whether agile practices actually produce better software, faster, doesn’t generate as much discussion. It’s as if a lack of faith in traditional software development methods—plagued by late projects, cost overruns and applications that don’t deliver business results—equals a belief in all things agile, despite the absence of data on agile’s impact.

Agile benefits—reduced time-to-market, better quality and improved predictability, among others—are widely recognized by they are not empirically proven. Still, agile shops offer anecdotal evidence that the approach works.

For some developers and managers agile has made the work more innovative, maintainable and predictable. I think it has enabled my development team to focus on what the business needs in ways that weren’t possible with waterfall. If your goal is to produce something people will use, agile is the best way to work.