Christophe Thibaut has been working as a consultant at OCTO since 2005. He has a 20 years experience in development, project management and project direction, as well as counselling for corporate companies. He has been practicing agile methodologies for the last 10 years, and has help dozens developers, architects and managers to understand and adopt these methodologies.
Christophe is interested in everything that allows the creation of better software faster, on a technical level (TDD, refactoring, OOP, functional programming) as well as a human level. He is passionate about helping every team to tap into its own greatness, and every manager to gain better results while enabling learning.
His expertise is based on a continuous learning process of the models used in these domains: XP, Scrum, Lean, coaching models and methods, shared vision process. He has a sharp communication verbal and written skills. He is a facilitator and a coach, an attentive observer, and active listener.
At OCTO, Christophe helps spreading TDD, review practices, agile management, coaching and change leadership. He facilitates project retrospectives, team and product vision work, and with his coaching team, contributes to the training of agile coaches at OCTO.
You are interested in functional programming but don't know where to start or even which language? Haskell is the language to play with in order to discover functional programming. It allows constructs that fits perfectly to that paradigm.
The problem is : Haskell is scary ! It comes with a uncommon syntax and a lot of fearful concepts (monads, functors, monoids, algebraic types, curryfication,…) The truth is : you don't need to master all these concepts to enjoy the power and the elegance of that language! Come play with Haskell, programming a Poker judge ! You'll be guided during this journey by two passionate haskellers who meet every week just for the sake of practice.
You'll leave this session with : a simple but powerful program written in Haskell able to be judge on a Texas Hold'em game many tests a lot of fun new skills usable as is on your current project!
Gently make haste, of Labour not afraid; A hundred times consider what you've said: Polish, repolish, every Colour lay, And sometimes add; but oft'ner take away. Boileau - Art PoÃ©tique
It's mainstream nowadays: everyone is Agile. But what does it mean to be Agile? It means opting for direct communication and collaboration, embracing change, striving for simplicity.. It also means fostering technical excellence, lest agile become fragile.
Now, to cultivate excellence, and respond in a better way to the customer's constraints and requests, we must learn. Learn about what? About that which schools -- engineering and other schools -- do not teach: we must learn our developer craft. This is where the fashion of the day disappears, and the old habits reappear. At work, one learns very slowly, and lessons, inasmuch as one is ready to listen to them, are expensive. Besides, the goal is not to learn, but to make.
And yet, where else could we be learning? Not in school, not in one's room, but on our project, with our team, everyday. Why is it difficult? There's no shortage of information. After all, do you know any development practice that isn't fully described on the internet?
But in the workplace the mental models -- not to mention prejudices -- die hard: specialization, individual performance, process: IT work is a factory!
The fact that our projects, agile or not, invariably end up being rushed and dashed, thus stopping us from taking the time to learn and get better at our craft, is undoubtedly the most remarkable irony of this industry. It's the same old story of the developers not having time to test their code, having all those bugs to fix!
Learning to progress in a continuous way with our team is both simple and difficult. Simple, because agreed-upon standard practices have been there ever since there were development teams. These practices are easy to put in place. And the difficult thing is that you have to decide to so first. And why is that hard? Because a change of models is necessary: these practices are not focused on process, tasks, roles, but on feedback, on the diffusion of know-how, and cultivating social skills. Farewell software
In this keynote, I will throw flares on the path of excellence, sharing about what I have been observing in the developer trade for more than two decades.
Room: keynote - Time: 5/13/2016 5:00:00 PM
Tests are your best assets to build your applications.
Using Behavior Driven Developement, your team find examples that describe the functionality your users want. With the right DSL and tooling, these examples become acceptance tests, a feedback at the functionnality level.
Test Driven Development guides the developer towards code that works, code that can easily and safely be changed using the quick, precise feedback of unit tests.
How do we mix these two flavors of tests into the developer workflow? One answer is to use many Red/Green/Refactor TDD to make an acceptance pass, and to continue until all your examples are handled. Big loops of acceptance tests made of fast TDD loops : this practice is known as Double Loop TDD.
During the session, you'll be practicing Double Loop TDD in a .NET environment, using Specflow and NUnit. You'll see how the two kind of tests articulates and how to harness their feedbacks.
Prerequisites : * Being acquainted with TDD * If you really want to get your hand dirty by yourself : Visual Studio 2015 with Specflow Extensions. * For others, we will use randori mode ;o)
Room: Brahma - Time: 5/12/2016 2:45:00 PM