You'll be rewarded by not doing dodgy stuff like spamming, manipulating your users into doing stuff, growth hacking your search rankings or faking your social media, or abusing your power to compete unfairly if you're successful.

This difference is one of the key distinctions between continuous improvement and first principles thinking. Continuous improvement tends to occur within the boundary set by the original vision.

Customer experience PMs should be in regular communication with cus-tomers to understand what they are looking for in a product, the types ofuser and their backgrounds, and the ways in which the product may beused.

There is a common view that software product engineering is simplyadvanced programming and that traditional software engineering is irrelevant.All you need to know is how to use a programming language plus the frame-works and libraries for that language. This is a misconception and I have writ-ten this book to explain the activities, apart from programming, that I believeare essential for developing high-quality software products.

Platform

If you read about software products, you may come across two other terms:“software product lines” and “platforms” (Table 1.1). Software product linesare systems designed to be adaptable to meet the specific needs of customersby changing parts of the source code. Platforms provide a set of features thatcan be used to create new functionality. However, you always have to workwithin the constraints defined by the platform suppliers.

I’m noteven going to give you a sales system, really; I’m giving you theframework to create your own.

Here’s the advantage in sales we introverts have over our extrovertedpeers: We don’t rely on our personality. In the absence of naturaltalent, we have to rely on a process...and in the long-run, processbeats personality. Every time.

By rehearsing three differenttopics, Alex doesn’t need to be spontaneous, nor does he have towait out those long pauses while he and the potential client findtheir verbal footing. He now goes into a meeting already prepared toinitiate—and, more important, control—the small talk. Establishingrapport is no longer a chore or a necessary evil. It’s a to do: a taskthat Alex is relaxed and prepared for because he already knows howthe routine goes.

Introverts, on the other hand, just rely on the system.

“Build it and they will come” maywork in the movies, but if that’s your strategy in business, you’re justcounting the days till you close your doors.

So, they concentrate on the work. Business owners oftengo into business for themselves because they’re great at theirfunctional skill. Lawyers start their own firms because they knowthe law. Electricians start their own electrical contracting companiesbecause they’re good electricians. IT professionals start their ownconsultancy business because they’re proficient with a specificplatform.But just because you’re good at something—or even great atit—doesn’t mean that customers will automatically show up atyour door.

Just as long-distance runners push through pain to experience the pleasure of “runner’s high,” I have largely gotten past the pain of my mistake making and instead enjoy the pleasure that comes with learning from it. I believe that with practice you can change your habits and experience the same “mistake learner’s high.”

The principles you choose can be anything you want them to be as long as they are authentic—i.e., as long as they reflect your true character and values

Think for yourself to decide 1) what you want, 2) what is true, and 3) what you should do to achieve #1 in light of #2 . . . . . . and do that with humility and open-mindedness so that you consider the best thinking available to you.

While it isn’t necessarily a bad thing to use others’ principles, adopting principles without giving them much thought can expose you to the risk of acting in ways inconsistent with your goals and your nature.

To be principled means to consistently operate with principles that can be clearly explained.

If instead we classify these situations into types and have good principles for dealing with them, we will make better decisions more quickly and have better lives as a result.

Principles are fundamental truths that serve as the foundations for behavior that gets you what you want out of life. They can be applied again and again in similar situations to help you achieve your goals.

Whatever success I’ve had in life has had more to do with my knowing how to deal with my not knowing than anything I know.

Strategy needn’t be the purview of a small set of experts. It can bedemystified into a set of five important questions that can (and should) beasked at every level of the business: What is your winning aspiration?Where should you play? How can you win there? What capabilities do youneed? What management systems would support it all? These choices,which can be understood as a strategic choice cascade, can be captured on asingle page.

The final strategic choice in the cascade focuses on management systems.These are the systems that foster, support, and measure the strategy.

Two questions flow from and support the heart of strategy: (1) whatcapabilities must be in place to win, and (2) what management systems arerequired to support the strategic choices? The first of these questions, thecapabilities choice, relates to the range and quality of activities that willenable a company to win where it chooses to play. Capabilities are the mapof activities and competencies that critically underpin specific where-to-play and how-to-win choices

To determine how to win, an organization must decide what will enable itto create unique value and sustainably deliver that value to customers in away that is distinct from the firm’s competitors. Michael Porter called itcompetitive advantage—the specific way a firm utilizes its advantages tocreate superior value for a consumer or a customer and in turn, superiorreturns for the firm.

Where to play selects the playing field; how to win defines the choices forwinning on that field. It is the recipe for success in the chosen segments,categories, channels, geographies, and so on. The how-to-win choice isintimately tied to the where-to-play choice. Remember, it is not how to wingenerally, but how to win within the chosen where-to-play domains.

The next two questions are where to play and how to win. These twochoices, which are tightly bound up with one another, form the very heart ofstrategy and are the two most critical questions in strategy formulation.

At Olay, the winning aspirations were defined as market share leadershipin North America, $1 billion in sales, and a global share that put the brandamong the market leaders. A revitalized and transformed Olay wasexpected to establish skin care as a strong pillar for beauty along with haircare. Establishing and maintaining leadership of a new masstige segment,positioned between mass and prestige, was a third aspiration.

The first question—what is our winning aspiration?—sets the frame for allthe other choices. A company must seek to win in a particular place and in aparticular way. If it doesn’t seek to win, it is wasting the time of its peopleand the investments of its capital providers. But to be most helpful, theabstract concept of winning should be translated into defined aspirations.Aspirations are statements about the ideal future. At a later stage in theprocess, a company ties to those aspirations some specific benchmarks thatmeasure progress toward them

Consider the salesperson in the Manhattan store. She defines winning asbeing the best salesperson in the store and having customers who aredelighted with her service.

The result is a set of nested cascades that cover the fullorganization (figure 1-2)

pecifically,strategy is the answer to these five interrelated questions:1. What is your winning aspiration? The purpose of your enterprise, itsmotivating aspiration.2. Where will you play? A playing field where you can achieve thataspiration.3. How will you win? The way you will win on the chosen playing field.4. What capabilities must be in place? The set and configuration ofcapabilities required to win in the chosen way.5. What management systems are required? The systems and measuresthat enable the capabilities and support the choices.

Our intent is to provide you with a do-it-yourself guide to strategy. Weoffer you the concepts, process, and practical tools you need to create anddevelop a winning strategy for your business, function, or organization—astrategy that serves your customers better and enables you to compete moresuccessfully and to win.

Strategy is a relatively young discipline. Until the middle of the lastcentury, much of what people now think of as strategy was categorizedsimply as management.

Taken together, the five choices, one framework, and one processprovide a playbook for crafting strategy in any organization.

While you might think that pairing less experienced engineers is a waste of time, every single time I had a less experienced engineer work by themselves, I ended up regretting it.

Passons en revue rapide les moyens pour développer les compétences au sein d’une organisation (service, entreprise, administration, association…) :le recrutement (apport de compétences externes pérenne) ;l’externalisation / la sous-traitance (apport de compétences externes ponctuel ou pérenne) ;la formation (apport de compétences internes pérenne) ;la redéfinition des postes de travail (meilleure adéquation des compétences internes) ;l’apprentissage sur le tas ou en situation de travail : l’apprenant développe seul ses compétences (développement individuel des compétences) ;l’accompagnement individuel : mentorat, coaching (déblocage et développement individualisé des compétences) ;la mise en place de groupes de qualité, pour la résolution de problèmes ou le codéveloppement (développement collectif des compétences internes) ;l’autoformation : assister à des conférences, se former en dehors des dispositifs, tenir une veille... (développement autonome des compétences internes).  

Quand vous lisez cette définition, vous pouvez remarquer des points importants. Le premier, c’est qu’il faut qu’il y ait écart ; le deuxième, c’est que cet écart concerne les compétences. Enfin, le troisième, c’est qu’on est centré à la fois dans le temps (“un moment donné”) et sur une personne (“un individu”).

Le “P” placé en début du PADDIE+M est quant à lui une phase de planning, qui permet de fixer un cadre temporel bien défini au projet. Cela est notamment nécessaire pour les projets d’envergure ou les projets contraints par le temps.

les objectifs pédagogiques (qui diffèrent des objectifs de formation)

Ils sont complémentaires et souvent “en cascade” : la définition des orientations permet d’aider à la conception des dispositifs. Chaque dispositif conçu nécessite d’être rendu opérationnel et requiert donc une ingénierie pédagogique.

À la fin de ce cours, vous serez capable de :analyser un besoin de formation ;designer un dispositif pertinent ;développer ce dispositif en équipe ;implémenter la formation ;évaluer l’action de formation.

L’ingénierie est un processus structuré et méthodique qui permet de passer de besoins opérationnels à la mise en œuvre d’une solution.

Cela correspondrait à ne pas faire le travail d’ingénierie, car il n’y aurait pas eu d’analyse.

The “Goals, Signals, Metrics” framework is the most important thing I learned from Ciera, while at Google. This is a framework for defining metrics:Define the actual goal you’re trying to accomplish. Opt for a descriptive definition, for example, say “here is a description of what we want to actually accomplish with our work.” Not the vaguer, “I want to measure X.”Define signals. How would you know if you accomplished that goal, if you had infinite knowledge of everything? These are called “signals.” For example, a signal is “how happy are people with my product?” You cannot directly know how happy people are with your product, unless you’re magically all-knowing. However, if having happy customers is one of your goals, then this is the right signal for that.Figure out your metrics. These are proxies for that signal. Metrics are always proxies, there are no perfect metrics.

You can’t ask everybody about everything, all of the time. This seemingly simple and straightforward statement was one of our most important learnings. It seems obvious when you say it out loud, but implementing this insight is more complicated!To implement the approach of asking developers different questions at different times, you use some math and observation. We needed to get statistically significant data over a certain period of time, for a certain population of developers. However, we set ourselves the constraint to only ask a developer one question, about one thing, every X number of days. So, we couldn’t ask about 300 different tools at once; we needed to narrow our questions down to larger workflows. Even with this narrowing, we could not get enough data unless we asked everybody about all of them, all of the time.Despite our efforts, we still needed to keep a developer survey in place. Developers are happier answering 30 questions in ten minutes, once a quarter, than getting a daily email with one question – even if it only takes 30 seconds to answer.’Note from Gergely: For its own reasons, Amazon does get employees to answer one question per day via the Connections app, as covered in Inside Amazon’s Engineering Culture.

Across the software industry, many companies have adopted the “religion” of being data-driven when it comes to user-facing products. It’s a big area of focus when training new Product Managers: how to collect data, how to present it, how to analyze it, and what to do with the results. However, this is not necessarily an area of focus for software engineers.

Engineering—The Practical Application of Science

Figure 4.5 What can you do to encourage or allow the stakeholders to modify their behavior to help achieve the business goal?

Both Behavior Driven Development and Test Driven Development are examples of Example Driven Development.

Acceptance tests often use a full or near-full application stack, whereas unit tests concentrate on individual components in isolation. Unit tests make it easier to focus on getting a particular class working and identifying what other services or components it needs. Unit tests also make it easier to detect and isolate errors or regressions. You’ll typically write many small unit tests in order to get an acceptance criterion to pass (see Figure 3.12). At the unit testing level, teams practicing BDD often use Test Driven Development, or TDD, to drive out the actual implementation

This is a typical BDD approach, often referred to as “outside-in”. As we implement a layer, we will discover other things it needs to function, other services it needs to call. We have a choice; we can either build these things straight away, or we can put them to one side, model them as an interface or a dummy class, and come back to them later. If the first approach works just fine for simpler problems, for more complex code it is generally much more efficient to stay focused on the work at hand.

Writing the executable specifications before writing the code is a great way to discover and flesh out the technical design you need in order to deliver the business goals. It helps you discover what domain classes would make sense, what services you might need, and how the services need to interact with each other. It also helps you think about how to make your code easy to test. And code that is easy to test is easy to maintain.

They aren’t too sure what this service should look like just yet, but they do know that it needs to give them a list of proposed departure times. And writing the glue code gives them the perfect opportunity to experiment with different API designs, and see what they like best.

The test reports will be generated using Serenity BDD,[7] an open source library that makes it easier to organize and report on BDD test results.

We can use examples like the ones Tracy and her team recorded as the basis for more formal acceptance criteria. In a nutshell, the acceptance criteria are what will satisfy stakeholders (and QA) that the application does what it’s supposed to do.

In this section, we’ll see how to take these business-focused examples and rewrite them in the form of executable specifications. You’ll see how you can automate these specifications, and how doing so leads to discovering what code you need to write. And you’ll see how these executable specifications can be a powerful reporting and living-documentation tool.

Often these conversations uncover uncertainty or complexity, which leads us to split features into smaller chunks. In Scrum, a User Story needs to be small enough to deliver in a single sprint. If a feature will take more than one sprint to build, it is good practices to split a it into several stories that can be delivered incrementally over several sprints. This way, the team can get feedback earlier and more often, which in turn reduces the risk of error.

Tracy uses a technique called Example Mapping[4] to make the discovery process more visual. She notes down these examples and rules using colored post-its on a wall: blue cards represent the business rules, and green cards represent examples and counter-examples of these rules. Pink cards represent questions that we don’t have answers for right now. A yellow card at the top of the board reminds us which feature or user story is being discussed.

Many teams find Impact Mapping (see Figure 3.3) a useful exercise to discover and prioritize high-level capabilities and features that can help deliver a business goal. Impact Mapping helps business and technical people discuss business goals through the prism of four fundamental question: "Why are we doing this (i.e. what are our business goals)?", "Whose behavior do we need to change (i.e. who are the key actors)?", "How might their behavior change (i.e. what changes in their behavior would help us achieve our business goals)", and "What software features might support this behavior change".

Figure 7.1 In this chapter we’ll look at how to make the automated executable specifications robustand maintainable.

The order here is important. When you plan features and stories, your principal aimshould be to deliver business value. Start out with what business value you intend toprovide B, then who needs the feature you’re proposing, c, and finally what featureyou think will support this outcome d

A key part of this practice involves defining scenarios, or concrete examples of howa particular feature or story works. These scenarios will help you to validate andextend your understanding of the problem, and they’re also an excellent communica-tion tool. They act as the foundation of the acceptance criteria, which you then inte-grate into the build process in the form of automated acceptance tests. In conjunctionwith the automated acceptance tests, these examples guide the development process,helping designers to prepare effective and functional user-interface designs and assist-ing developers to discover the underlying behaviors that they’ll need to implement todeliver the required features.

Figure 1.11 High-level and low-level executable specifications generate different sorts of livingdocumentation for the system

This notation eventually evolved into a commonly used form often referred to asGherkin.

Domain-Driven Design,13 which promotes the use of a ubiquitouslanguage that business people can understand to describe and model a system.

North observed that a few simple practices, such as naming unit tests as full sen-tences and using the word “should,” can help developers write more meaningful tests,which in turn helps them write higher quality code more efficiently. When you think interms of what the class should do, instead of what method or function is being tested, it’seasier to keep your efforts focused on the underlying business requirements.

Despite its advantages, many teams still have difficulty adopting and using TDDeffectively. Developers often have trouble knowing where to start or what tests theyshould write next. Sometimes TDD can lead developers to become too detail-focused,losing the broader picture of the business goals they’re supposed to implement. Someteams also find that the large numbers of unit tests can become hard to maintain asthe project grows in size.

Behavior-Driven Development ( BDD) is a set of software engineering practicesdesigned to help teams build and deliver more valuable, higher quality software faster.It draws on Agile and lean practices including, in particular, Test-Driven Development(TDD) and Domain-Driven Design ( DDD). But most importantly, BDD provides a com-mon language based on simple, structured sentences expressed in English (or in thenative language of the stakeholders) that facilitate communication between projectteam members and business stakeholders.

As practitioners, we like to keep things grounded in real-world examples, soin chapter 2 you’ll see what BDD looks like in a real project, all the way from dis-covering the requirements and automating the high-level acceptance criteria tobuilding and verifying the design and implementation, through to producingaccurate and up-to-date technical and functional documentation.

The goal of this book is to help get teams up and running with effective BDD practices.It aims to give you a complete picture of how BDD practices apply at all levels of thesoftware development process, including discovering and defining high-level require-ments, implementing the application features, and writing executable specificationsin the form of automated acceptance and unit tests.

pecification by Example, agileacceptance testing, Behavior-Driven Development, and all the alternative names for thesame thing solve these problems. This book will help you get started with those prac-tices and learn how to contribute better to your team, regardless of whether you qualifyyourself as a tester, developer, analyst, or product owner.

If you’re a practitioner, like me, and your bread and butter come from making or helpingsoftware go live, this book has a lot to offer. I primarily wrote this book for teams whohave tried to implement an agile process and ran into problems that manifest themselvesas poor quality, rework, and missed customer expectations. (Yes, these are problems, andplainly iterating is a workaround and not a solution.)

It presents the collectiveknowledge of about 50 projects, ranging from public websites to internal back-officesystems. These projects involved diverse teams, from small ones working in the same of-fice to groups spread across different continents, working in a range of processes includ-ing Extreme Programming (XP), Scrum, Kanban, and similar methods (often bundledtogether under the names agile and lean). They have one thing in common—they all gotthe practices of collaborating on specifications and tests right, and they got big benefitsout of that.

How to set up your Software Development Teams?This is one of the most important questions to consider when working to create great software.