What do you think?
Rate this book
Robert C. Martin Series
Чистий Agile: назад до основ
За майже 20 років, які минули від опублікування Маніфесту Agile, розуміння цієї методології стало суттєво відрізнятися від тих намірів, котрі було покладено в основу її творцями. Тож зараз саме час повернутися до оригінальної ідеї Agile: негроміздкого рішення маленького завдання, поставленого перед невеликими командами програмістів, які виконують дрібні завдання. А хто може допомогти в цьому краще за Дядька Боба — одного з авторів гнучкої розробки програмного забезпечення, відомого міжнародного консультанта та письменника Роберта С. Мартіна, чиї книжки «Чиста архітектура» та «Чистий код» стали настільними для багатьох програмістів.
224 pages, Hardcover
First published January 1, 2019
311 people are currently reading
2563 people want to read
About the author
Robert C. Martin
56 books1,902 followersRobert Cecil Martin, commonly called Uncle Bob, is a software engineer, advocate of Agile development methods, and President of Object Mentor Inc. Martin and his team of software consultants use Object-Oriented Design, Patterns, UML, Agile Methodologies, and eXtreme Programming with worldwide clients.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
He was Editor in Chief of the C++ Report from 1996 to 1999. He is a featured speaker at international conferences and trade shows.
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 154 reviews
October 9, 2019
This book talks about the history of Agile and, as the subtitle suggests, the basics of it. It also tries to bring some sanity to the subject. Great to see Bob’s perspective after 18 years of the Agile Summit in 2001. It was a pleasure for me to write the chapter on Software Craftsmanship and contribute to this book.
December 11, 2019
Great back-to-basics overview and historical perspective.
January 26, 2020
This book is not an introductory text. Indeed, it requires that you'd been in the software industry for the last years because it's a deep analysis of the Agile movement and how and why it was created, and how it has evolved and adopted by the teams and companies.
Robert Martin's vision is clear here. The Agile ideas were good. They tried to solve common problems that the development companies had all around the world. But since its release, the ideas and principles were turned into a completely different animal. And that's the impression of one of the Agile Manifesto authors.
If you read this book, you probably realize that you were already lived some of the situations described there. And probably, if you are in contact with the community, you were also read/heard about the problems of the Agile movement nowadays. I love the concepts and ideas that make Agile up, but as Robert Martin also thinks, this is a little out of control.
Agile became an industry, and now it looks like it's more important to have an extensive amount of badges and certifications, to know how to scale a thing that it's not intended to be done at scale, to not have agile practitioners but coaches that bring no real value (because they excel on the processes, but not in the engineering), or Jira haters, or... The list is very long for me. So, citing the book, "You might say that Agile has become something akin to a religion in the realm of software development".
So, I strongly recommend to read it, even if you agree or not with the ideas and conclusions. This book is a journey, from the problems that Agile tried to solve, passing into the solution proposed and how it's supposed to help and ending in what's the situation today.
For me, is a must-read and refreshing text.
Robert Martin's vision is clear here. The Agile ideas were good. They tried to solve common problems that the development companies had all around the world. But since its release, the ideas and principles were turned into a completely different animal. And that's the impression of one of the Agile Manifesto authors.
If you read this book, you probably realize that you were already lived some of the situations described there. And probably, if you are in contact with the community, you were also read/heard about the problems of the Agile movement nowadays. I love the concepts and ideas that make Agile up, but as Robert Martin also thinks, this is a little out of control.
Agile became an industry, and now it looks like it's more important to have an extensive amount of badges and certifications, to know how to scale a thing that it's not intended to be done at scale, to not have agile practitioners but coaches that bring no real value (because they excel on the processes, but not in the engineering), or Jira haters, or... The list is very long for me. So, citing the book, "You might say that Agile has become something akin to a religion in the realm of software development".
So, I strongly recommend to read it, even if you agree or not with the ideas and conclusions. This book is a journey, from the problems that Agile tried to solve, passing into the solution proposed and how it's supposed to help and ending in what's the situation today.
For me, is a must-read and refreshing text.
February 14, 2020
It's good to be reminded what was Agile (is it a noun now?) all about in the beginning, before it became distorted beyond all recognition by the industry. The book should probably be obligatory for everyone working in IT. Although, I don't agree with everything, especially with the critique of Agile Lifecycle Management (ALM) systems and I don't think that implementation of the presented practices is as easy as Uncle Bob says. If it would be that easy, there wouldn't be so much struggle, especially in big organizations.
What I did like is how savage Uncle Bob is about Agile certification programs. Some quotes:
"The Agile certifications that exists are complete joke and utter absurdity. (...)"
"(...) For example, the fact that someone is certified a Scrum Master is worthless certification".
Ouch.
What I did like is how savage Uncle Bob is about Agile certification programs. Some quotes:
"The Agile certifications that exists are complete joke and utter absurdity. (...)"
"(...) For example, the fact that someone is certified a Scrum Master is worthless certification".
Ouch.
December 31, 2020
بیشتر از هرچیزی داستان اجایل هست. به نظر من داستان قشنگی هم هست. و البته که خودش هم ادعای خیلی بیشتری نداره گمونم.
کلی هم جملههای قشنگ قابل نقل قول داره. سخنِ بزرگانطور.
کلی هم جملههای قشنگ قابل نقل قول داره. سخنِ بزرگانطور.
August 1, 2024
1st read (Dec 2022) 3/5:
In my opinion this book is a worse summary of other classic development books (XP, Refactoring) mixed with some personal anecdotes from Uncle Bob. It contained a lot of the contents from XP but I liked the XP book way more.
I would say this book is an additional read and that there are better sources out there about Agile (even though Bob was one of the authors of the Agile Manifesto 😂).
Anyways there were some good chapters: Refactoring, TDD, Pair Programming, Simple Design are highly valuable practices in Agile Development Teams and it is conforming to read this again and again.
2nd read (July 2024) 5/5:
A deep and direct insight into how Agile came to be and what it really is. Highly valuable content because I realized how simple Agile was meant to be.
Summarized in my own words:
1. work in small steps
2. measure the outcome
3. refine and try to make estimations based on collected data
Then iterate on that again and again, keep learning…
That’s basically it.
In my opinion this book is a worse summary of other classic development books (XP, Refactoring) mixed with some personal anecdotes from Uncle Bob. It contained a lot of the contents from XP but I liked the XP book way more.
I would say this book is an additional read and that there are better sources out there about Agile (even though Bob was one of the authors of the Agile Manifesto 😂).
Anyways there were some good chapters: Refactoring, TDD, Pair Programming, Simple Design are highly valuable practices in Agile Development Teams and it is conforming to read this again and again.
2nd read (July 2024) 5/5:
A deep and direct insight into how Agile came to be and what it really is. Highly valuable content because I realized how simple Agile was meant to be.
Summarized in my own words:
1. work in small steps
2. measure the outcome
3. refine and try to make estimations based on collected data
Then iterate on that again and again, keep learning…
That’s basically it.
April 1, 2021
This is that kind of book that you need to read ignoring the author that is not a good human being.
A summary of this book would be: read the Kent Beck's eXtreme Programming Explained and ignore all the Agile bullshit. And I agree with that part.
Some arguments ignores some situations that happens in a real software project (eg. how to handle when some developers leave the team or when we hire a new, not so experienced, developer to work in a already running project?).
There are some chapters written by guests and some of these chapters are pure crap trying to sell "coach certifications" and others are really good like the Craftsmanship chapter.
It is a quick reading and it would be a good book for non-devs understand some aspects of the Agile *Software* Development.
A summary of this book would be: read the Kent Beck's eXtreme Programming Explained and ignore all the Agile bullshit. And I agree with that part.
Some arguments ignores some situations that happens in a real software project (eg. how to handle when some developers leave the team or when we hire a new, not so experienced, developer to work in a already running project?).
There are some chapters written by guests and some of these chapters are pure crap trying to sell "coach certifications" and others are really good like the Craftsmanship chapter.
It is a quick reading and it would be a good book for non-devs understand some aspects of the Agile *Software* Development.
January 29, 2022
Gandrīz neticās, ka tas bija pirms 20 gadiem, bet es atceros to telpu un brīdi, kad pacēlu roku, atbildot uz jautājumu, kurš būtu gatavs pamēģināt šo jauno pieeju - agile. Kopš pirmā brīž tā man izklausījās dabiska, saprātīga un produktīva. Pro-duk-tī-va! Tikt līdz rezultātam visjēdzīgākajā, reālistiskjā veidā, izmantojot dabas dotos un izkoptos talantus un prasmes. Tā es kļuvu par convert un neesmu to nožēlojusi nevienu brīdi.
Šīs grāmatas pārlasīšana bija kā pārlasīt pirmā sludinātāja piezīmes par idejas dzīvi 20 gados, norādot uz pārpatumiem, atkārtojot būtību. Saskanīgi. Idejā, manī un praksē viss vēl joprojām sader bez mazākās pretrunas.
Agile values: Courage. Communication. Feedback. Simplicity.
Agile vērtības: Drosme. Komunikācija. Atgriezeniskā saite. Vienkāršība.
Šīs grāmatas pārlasīšana bija kā pārlasīt pirmā sludinātāja piezīmes par idejas dzīvi 20 gados, norādot uz pārpatumiem, atkārtojot būtību. Saskanīgi. Idejā, manī un praksē viss vēl joprojām sader bez mazākās pretrunas.
Agile values: Courage. Communication. Feedback. Simplicity.
Agile vērtības: Drosme. Komunikācija. Atgriezeniskā saite. Vienkāršība.
August 27, 2021
It is very interesting how we usually change the meaning of concepts over time and the original meaning is lost.
To recover the original meaning, it is necessary to have a context in which this concept was created and Uncle Bob is one of the best storytellers possible to do that job.
Because it is so short (and I think it could be even shorter), everyone involved with Agile should read it.
---
"Agile is a small discipline that helps small software teams manage small projects. But despite all that smallness, the implications and repercussions of Agile are enormous because all big projects are, after all, made from many small projects."
(...)
"What about Agile in the large? I don’t think there is such a thing. Organizing large teams is a matter of organizing them into small teams. Agile solves the problem for small software teams; the problem of organizing small teams into larger teams is a solved problem. Therefore, my answer to the question of Agile in the large is simply to organize your developers into small Agile teams, then use standard management and operations research techniques to manage those teams. You don’t need any other special rules."
To recover the original meaning, it is necessary to have a context in which this concept was created and Uncle Bob is one of the best storytellers possible to do that job.
Because it is so short (and I think it could be even shorter), everyone involved with Agile should read it.
---
"Agile is a small discipline that helps small software teams manage small projects. But despite all that smallness, the implications and repercussions of Agile are enormous because all big projects are, after all, made from many small projects."
(...)
"What about Agile in the large? I don’t think there is such a thing. Organizing large teams is a matter of organizing them into small teams. Agile solves the problem for small software teams; the problem of organizing small teams into larger teams is a solved problem. Therefore, my answer to the question of Agile in the large is simply to organize your developers into small Agile teams, then use standard management and operations research techniques to manage those teams. You don’t need any other special rules."
November 29, 2019
A must-read for everyone involved on software engineering. Well, if you really want quality and functional software, whether you are an engineer or an executive.
This book is an oasis of knowledge and principles in times like these when Agile is being totally misinterpreted by people who want to do old, unprofessional and ineffective management practices with new "agile" names, roles and complex "scaled" frameworks. It has tons of experience, results and skin in the game in form of sentences.
This book is an oasis of knowledge and principles in times like these when Agile is being totally misinterpreted by people who want to do old, unprofessional and ineffective management practices with new "agile" names, roles and complex "scaled" frameworks. It has tons of experience, results and skin in the game in form of sentences.
January 7, 2020
I'm a Robert C. Martin fan, but this book is the same content from videos and other presentations all over repeated again. There is nothing new. Maybe, for newcomers to the Uncle Bob world, it can be fun to read and they can be delighted by his pragmatism. However, nothing new in the shop. Maybe he could try with different content that we are not so used to from him such us functional programming, for example.
December 28, 2019
A huge disappointment and easily the worst book from Uncle Bob. There is nothing in this book that wasn't already published; most of ideas are borrowed from Pragmatic Programmer. The chapter about agile coaches written by another guy, which contradicts the author's opinion, is totally out of place. The whole book can be three time shorter and still tell the same story.
January 25, 2020
Agile is like teenage sex - all claim to be doing it but nobody really does properly. This book offers a great introduction to the original foundations of Agile.
April 3, 2021
Vale para quem tem pouca experiência em atuar com métodos ágeis.
Para quem já é experiente, não agrega muita coisa.
De certo modo achei um pouco decepcionante, rasa e vaga a opinião do autor sobre os métodos de agilidade em escala como SAFe e Less, que estão na moda. A opinião se resume a: métodos ágeis são para equipes pequenas, mas que o problema de gerenciar grandes equipes "já está resolvido", pois é só dividir uma equipe grande em várias pequenas. (Será?)
Mas ele mesmo admite que não pesquisou a fundo o assunto (!!!), o que se enxerga claramente uma vez que ele nem se dá ao trabalho de explicar o que cada um desses métodos de agilidade em escala prega.
Para quem já é experiente, não agrega muita coisa.
De certo modo achei um pouco decepcionante, rasa e vaga a opinião do autor sobre os métodos de agilidade em escala como SAFe e Less, que estão na moda. A opinião se resume a: métodos ágeis são para equipes pequenas, mas que o problema de gerenciar grandes equipes "já está resolvido", pois é só dividir uma equipe grande em várias pequenas. (Será?)
Mas ele mesmo admite que não pesquisou a fundo o assunto (!!!), o que se enxerga claramente uma vez que ele nem se dá ao trabalho de explicar o que cada um desses métodos de agilidade em escala prega.
October 30, 2022
Good write-up, opinion and ranting about the problems with agile adoption in businesses.
February 9, 2021
I always had a blurry picture of what Agile actually means, and why we practice it.
Well, not anymore.
If you and your teammates don't care about the following and you still think you are an "Agile" team, I have news for you: You are not! and if anyone tells you otherwise, watch out, because he is full of BS (:
Test-Driven Development, Refactoring, Pair Programming, Continues Integration and Delivery, Clean Code ...
These are just the technical practices of Agile. If you wanna know why these practices are key, you can read the book. This book is a history and review of Agile principles, disciplines, and its business, team, and technical practices.
It’s also a fresh perspective (revised edition) 20 years after Agile Manifesto was born and how was the adaptation in the industry so far.
I developed a more clear understanding of Agile as a way to make successful software development achievable in small teams.
Great read. I love Robert Martin's insights. He is truly a legend in the field.
It's for anyone who is a part of a software development team from Managers, QAs, Business Analysts, developers…
Well, not anymore.
If you and your teammates don't care about the following and you still think you are an "Agile" team, I have news for you: You are not! and if anyone tells you otherwise, watch out, because he is full of BS (:
Test-Driven Development, Refactoring, Pair Programming, Continues Integration and Delivery, Clean Code ...
These are just the technical practices of Agile. If you wanna know why these practices are key, you can read the book. This book is a history and review of Agile principles, disciplines, and its business, team, and technical practices.
It’s also a fresh perspective (revised edition) 20 years after Agile Manifesto was born and how was the adaptation in the industry so far.
I developed a more clear understanding of Agile as a way to make successful software development achievable in small teams.
Great read. I love Robert Martin's insights. He is truly a legend in the field.
It's for anyone who is a part of a software development team from Managers, QAs, Business Analysts, developers…
January 3, 2020
This book consists of three parts:
1. Short memoir about the meeting where Agile Manifesto had been initiated. Interesting, even, as "Uncle Bob" himself admits he did not check any sources and trusted his memory only and many other participants described it differently.
2. Description of what Agile is - from team, individual, company perspective. It's very confusing part. While the author himself agreed before that "Agile"!= XP all he describes as "Agile" is actually XP. He talks (mostly negatively) about Scrum a bit, and that's it.
Some of his opinions are really weird. E.g., he says that there is no need to talk about "Agile in large", because organizations of small teams in a big project was solved "5000 years ago". Does he really adhere to CEO of Volkswagen opinion that "dieselgate"is about 2 engineers who wrote wrong software code for testing an engine performance?
3. The third part is a couple of essays from different authors about Agile coaching and Software Craftmanship movements - these essays mostly contradicts "Uncle Bob" part 1. and part 2 and it's difficult to understand why did he put them in his book besides making it 200 pages instead of 150.
1. Short memoir about the meeting where Agile Manifesto had been initiated. Interesting, even, as "Uncle Bob" himself admits he did not check any sources and trusted his memory only and many other participants described it differently.
2. Description of what Agile is - from team, individual, company perspective. It's very confusing part. While the author himself agreed before that "Agile"!= XP all he describes as "Agile" is actually XP. He talks (mostly negatively) about Scrum a bit, and that's it.
Some of his opinions are really weird. E.g., he says that there is no need to talk about "Agile in large", because organizations of small teams in a big project was solved "5000 years ago". Does he really adhere to CEO of Volkswagen opinion that "dieselgate"is about 2 engineers who wrote wrong software code for testing an engine performance?
3. The third part is a couple of essays from different authors about Agile coaching and Software Craftmanship movements - these essays mostly contradicts "Uncle Bob" part 1. and part 2 and it's difficult to understand why did he put them in his book besides making it 200 pages instead of 150.
January 25, 2020
The first disappointment by Uncle Bob. I don't think I will ever return to this book for whatever reason. It's a shame though! I just love all of his other books! But this one... I didn't find any value in it. Furthermore, 20-25% of the content is taken from other authors (with permission!). It feels like he was forced by his publishers to write this book although he hadn't that much important stuff to say. There are much better books on the topic. I'm just glad I read the book before I purchased the videos :-(
December 1, 2019
Um livro que precisava ter sido escrito uns 15 anos atrás! Alguns conteúdos são completamente dispensáveis, o que poderia tornar o livro ainda mais enxuto. Apesar disso, a riqueza de conteúdo que o autor conseguiu colocar em 200 páginas é algo que eu não via em um livro sobre o tema há muito tempo. É uma definição completa sobre o que é o desenvolvimento ágil de software, desassociando dele toda a bullshitagem da "cena ágil" atual.
September 24, 2020
This is probably not a must-read, but still a very interesting, thoughtful and personal perspective on Agile. Martin brings the often forgotten developers side to the equation and strongly advertises software craftsmanship as a way to incorporate the often forgotten and ignored parts of agile (XP, TDD, Pair Programming, ...) into today’s organizations. With this the book is an important contribution to the history of agile!
January 23, 2020
I feel this book is just repeating all the essentials of earlier books in this Clean Code series. Though, it does add new materials taken from Uncle Bob's experiences
September 11, 2021
I find it educational but with too much repetition of some of the practices. But I think you can get a lot of value from it. Must read for a software developer nowadays.
March 29, 2020
This book was a mix of memory lane, tips and essays from others.
The preface explains that this is a small book because it solves a small problem. The author reminisces about the the Snowbird meeting and the start tho the agile manifesto. He talks about 4 agile frameworks. (It's been a while since I thought about XP).
I like that he asks you to count the number of computers in your life. (Did you remember to count things like your clock and DVR). It was fun hearing the origin of the term “checkout” for source code. (from checking out physical punch cards from the drawer).
There are many good examples and stories throughout. I liked “Who is training the new people? The people who made the mess in the first place”. The point that the outer circle of Scrum is a “highly efficient way to make a large mess.”
The last two chapters were essays written by others, but they fit well. We are currently on lockdown due to coronavirus, but I look forward to passing this book around when I see people again!
The preface explains that this is a small book because it solves a small problem. The author reminisces about the the Snowbird meeting and the start tho the agile manifesto. He talks about 4 agile frameworks. (It's been a while since I thought about XP).
I like that he asks you to count the number of computers in your life. (Did you remember to count things like your clock and DVR). It was fun hearing the origin of the term “checkout” for source code. (from checking out physical punch cards from the drawer).
There are many good examples and stories throughout. I liked “Who is training the new people? The people who made the mess in the first place”. The point that the outer circle of Scrum is a “highly efficient way to make a large mess.”
The last two chapters were essays written by others, but they fit well. We are currently on lockdown due to coronavirus, but I look forward to passing this book around when I see people again!
September 21, 2023
An excellent book describing the origins of Agile, where we are with Agile and where we should go next. A lot of the problems described will be familiar for everyone. The problems fall at the feet at those that use Agile for marketing purposes and how it became a process for PMs rather than a technical collaborative effort.
The book doesn't ever look at the issues of Dev who don't treat what they do as a craft. From my experience, they are also one of the biggest issues and make some Agile teams impossible (whether they are hands on developers or testers) but it does address why Agile Coaches aren't generally qualified to solve this issue.
All in all, a great book. There are no magic bullets to help team, just a focus on simplicity and taking one step forward in how you work at a time.
The book doesn't ever look at the issues of Dev who don't treat what they do as a craft. From my experience, they are also one of the biggest issues and make some Agile teams impossible (whether they are hands on developers or testers) but it does address why Agile Coaches aren't generally qualified to solve this issue.
All in all, a great book. There are no magic bullets to help team, just a focus on simplicity and taking one step forward in how you work at a time.
July 13, 2022
It was... okay. I like the focus back to the roots, but dislike the criticism you feel throughout the book. Yes, there is a lot of criticism due to the industry, but this book does not help building bridges, but takes a high ground. Yet: I totally recommend the first half of the book about everything fundamental about Agile.
September 29, 2023
I truly enjoyed this book! Working in software development as an Agile Leader with a non-technical background, I loved how this book talked about the VALUE of agile, some history of agile ideology, and how interrelated it is to coding software. It was very easy to read and comprehend. Additionally, it gave me some great ideas to take back to the software development teams I coach.
April 18, 2024
Wish I’d read this years ago when I was going at software companies.
Fast read too, hits all the major definitions, and provides threads to tug on if you want to dig deeper
Fast read too, hits all the major definitions, and provides threads to tug on if you want to dig deeper
January 25, 2025
Замітки з книги:
“обмежує всі проєкти й накладає обмеження згідно з правилом хреста. Добре, швидко, дешево, готово. Оберіть будь-які три складники, які вам подобаються. Але четвертий ви подужати не зможете.”
“Agile — це комплекс методів, який допомагає розробникам та менеджерам здійснювати прагматичне управління проєктами.”
“Agile — це насамперед підхід, орієнтований на зворотний звʼязок. Кожен тиждень, день, година та хвилина визначаються результатами попереднього тижня, дня, години та хвилини, і потім уносяться відповідні корективи. Це застосовується як до окремих програмістів, так і до управління всією командою. Без даних важко належно керувати проєктом’”
“Аналіз можна розуміти як розбиття проєкту на структурні елементи (декомпозиція). Або ж як виявлення та розробку вимог. Можна як створення базової моделі даних або обʼєктної моделі тощо…”
“Етап проєктування програмного забезпечення для нас зрозумілі-ший. Він полягає в розділенні проєкту на модулі й створенні інтерфейсів між ними.”
“Аналіз та проєктування не працюють у парі як показники результативності. У них немає однозначних критеріїв завершеності.”
“Спринт — термін, який використовують у Scrum. Мені він не подобається, бо має на увазі, що потрібно мчати стрімголов. Проект із розробки програмного забезпечення — марафон, а хто на марафоні вдається до спринту?”
“Головна мета Agile - позбутися марних надій. Ми практикуємо Agile, щоб знищити надію, перш ніж вона спричинить «смерть» проєкту. Надія вбиває проєкт. Це те, що змушує ко��анду з розробки програмного забезпечення вводити в оману менеджерів щодо її реального просування вперед. Коли менеджер запитує команду: «Як ідуть справи?», то в самому запитанні вже жевріє надія на відповідь «Дуже добре». Надія — дуже поганий спосіб управління програмним проєктом. A Agile — це спосіб забезпечити своєчасну й безперервну дозу холодної, суворої реальності навзамін надії.”
“Менеджери керують програмними проєктами, збираючи дані, а потім ухвалюють на їх основі найкращі рішення з можливих. Agile виробляє дані. Багато даних. Менеджери використовують їх, щоб привести проєкт до найкращого можливого результату.”
“Закон Брукса стверджує: «Додавання робочої сили до проєкту, здача якого затягується, затримує його ще більше». [Brooks, Jr., F. P. 1995 [1975]. The Mythical Man-Month. Reading, MA: Addison-Wesley.]”
“Для цієї книжки я дібрав методи екстремального програмування, оскільки з усіх методологій Agile воно є найкращим, найвизна-ченішим, найповнішим та найменш заплутаним. Практично всі інші процеси Agile є підмножиною або варіацією екстремального програмування.”
“Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston, MA: Addison- Wesley. Існує й друге видання, датоване 2005 роком, але перше — моє улюблене, і я вважаю саме його кінцевим варіантом.”
“акцент Agile на тестуванні, рефакторингу, простоті дизайну та відгуках клієнтів — це очевидний лікувальний засіб від продукування поганого коду.”
“Ступінь легкості впровадження змін у програмне забезпечення вказує на те, наскільки сама команда заважає створенню ефективного програмного забезпечення. Клієнти, користувачі та менеджери очікують, що програмне забезпечення буде легко змінити, а вартість таких змін буде невеликою та пропорційною.”
“Agile не процес. Agile не тренд. Agile не просто набір правил. Це, найвірогідніше, сукупність прав, очікувань та методів, яка складає основу професійної етики.”
“можу порекомендувати вивчити техніку оцінювання та аналізу програм і проєктів (PERT) [https://en.wikipedia.org/wiki/Program...]”
“Історія користувача - це скорочений опис функцій програми, розказаний з погляду користувача.”
“оцінювання відбувається не за часовими пара-метрами, а за складністю виконання. Одиниці складності історії мають бути лінійними. Картка з оцінкою 2 повинна вимагати приблизно половини зусиль картки з оцінкою 4. Однак лінійність не повинна бути ідеальною.”
“час спланувати першу ітерацію. Перший крок - зустріч, присвячена її плануванню. Ця зустріч повинна тривати одну двадцяту всієї ітерації. Тобто для двотижневої ітерації зустріч має тривати близько пів дня. На зустріч, присвячену плануванню ітерації, має зʼявитися вся команда, тобто програмісти, тестувальники, керівник проєкту, а також зацікавлені сторони. Останні мають попередньо прочитати оцінювані історії та відсортувати їх у порядку цінності для свого бізнесу.”
“Важливо усвідомити, що швидкість не є обовʼязком. Команда не обіцяє виконати 30 одиниць за час ітерації. Вона навіть не обіцяє зробити спробу в цьому напрямку. Це не що інше, як здогадка про те, скільки одиниць за найкращого розвитку подій буде завершено до кінця ітерації. Таке передбачення не дуже точне.”
“квадранти використовуються для розрахунку рентабельності інвестицій (ROI). Це неформальний підхід, і математика тут не потрібна. Зацікавлені сторони просто дивляться на картку й роблять висновки на основі цінності та складності історії.”
“Мета ітерації - генерувати дані для менеджерів.”
“Користувацькі історії — це прості висловлювання, застосовувані нами як нагадування про функції. Ми намагаємося не занотовувати занадто багато подробиць, коли пишемо історію, бо знаємо, що ці деталі, імовірно, зміняться. Подробиці записують пізніше, але у формі приймальних тестів,”
“Історії мають відповідати критеріям якості, закладеним в абревіатурі INVEST.”
“Незалежність (І — Independent). Історії користувачів незалежні одна від одної. Це означає, що їх не потрібно реалізовувати в якомусь конкретному порядку. До прикладу, після входу в систему не потрібно одразу реалізовувати функцію виходу. Це нежорстка вимога, бо цілком можуть існувати історії, які залежать від інших, котрі потребують першочергової реалізації.”
“Придатність для обговорення (N - Negotiable). Це ще одна причина, чому ми не записуємо всі деталі. Ми хочемо, щоб вони стали предметом обговорення розробників та замовників.”
“Цінність (V - Valuable). Цінність історії для замовника повинна бути чітко окресленою й вимірюваною.”
“Рефакторинг ніколи не вважають історією. І архітектуру також. Та й наведення ладу в коді. Історія — це завжди те, що містить у собі цінність для клієнта.”
“історія пройде крізь усі рівні системи. Вона може частково містити трохи графічного інтерфейсу, проміжного програмного забезпечення, баз даних тощо. Сприйміть історію як тонкий вертикальний зріз крізь горизонтальні прошарки системи.”
“Піддається оцінці (Е — Estimable). Користувацька історія повинна бути достатно конкретною, щоб розробники могли її оцінити.”
“Малий обсяг (S — Small). Користувацька історія не повинна бути великою, щоб бути реалізованою одним або кількома розробниками за одну ітерацію.”
“Не слід давати можливість одній історії домінувати в роботі всієї команди протягом цілої ітерації. Ітерація повинна містити приблизно стільки ж історій, скільки розробників є в команді. Якщо в команді 8 розробників, то кожна ітерація повинна містити приблизно від 6 до 12 історій. Однак ви ж не хочете заплутатися у вирішенні цього питання. Це більше рекомендація, аніж правило.”
“Придатність для тестування (Т - Testable). Клієнт повинен мати можливість обрати тести, які підтвердять, що історію завершено.”
“Зазвичай ці тести пишуть спеціалісти з перевірки якості (QA-спеціалісти), вони будуть автоматизовані та використовуватимуться для перевірки того, чи завершено історію.”
“Grenning, J. W. 2002. Planning Poker or how to avoid analysis paralysis while release planning. Доступ за адресою https://wingman-sw.com/articles/plann...”
“Розбиття історій — трохи цікавіше заняття, оскільки вам потрібно дотримуватися критеріїв INVEST. Як простий приклад розбиття історії розглянемо вхід (залогування). Якщо ми побажаємо розділити його на більш дрібні історії, то можна створити такі: вхід без пароля, вхід з однією спробою, дозволити кілька спроб уведення пароля та забули пароль.”
“Метою кожної ітерації є отримання даних шляхом виконання істо-рій. Команда повинна зосереджуватися на історіях, а не на завданнях, які лежать в їхніх межах. Набагато краще зробити 80 % історій, ніж кожну історію на 80 %. Зосередьтеся на доведенні історій до завершення.”
“У менеджерів та ведучих буде спокуса призначати програмістам історії. Та цього слід уникати. Набагато краще дозволити програмістам самим між собою домовлятися.”
“Якщо спеціалісти з контролю якості ще не почали писати автоматизовані приймальні тести, то щойно завершиться зустріч із приводу планування ітерації, уже час починати. Тести для історій, які заплановано виконати серед перших, слід підготувати якнайраніше. Завершені історії не мусять чекати, коли приймальні тести будуть нарешті готові.”
“Написання приймального тесту повинно проходити швидко. Ми очікуємо, що всі вони будуть готові до середини ітерації. Якщо не всі приймальні тести буде створено до середини, то деяким розробникам слід припинити роботу над історіями й почати працювати над приймальними тестами.”
“Якщо спеціалісти з контролю якості продовжують провалювати написання тестів до середини кожної ітерації, то, імовірно, співвідношення інженерів з контролю якості та розробників неправильне.”
“Коли історія пройшла приймальні тести, її можна вважати завершеною.”
“Кожна ітерація закінчується короткою демонстрацією нових історій для зацікавлених сторін. Ця зустріч повинна тривати не більше однієї двох годин, залежно від розміру ітерації.”
“Найкраще, якщо самі зацікавлені сторони перевірять роботу системи, аби розробники не спокушалися можливістю приховувати те, що не працює.”
“Графік швидкості говорить нам про те, наскільки добре керують командою. Графік швидкості буде доволі спотвореним, особливо під час перших ітерацій, оскільки команда ще зʼясовуватиме основи проєкту. Але після кількох ітерацій неточності повинні знизитися до рів-ня, який би дозволив визначити середню швидкість робіт.”
“Ми не розраховуємо, що команда буде прискорюватися або ж уповільнюватися протягом тривалого часу.”
“Спадання швидкості. Якщо графік швидкостей показує стійкий негативний ріст, то найбільш вірогідною причиною є якість коду. Команда, імовірно, застосовує недостатньо рефакторинга, і код починає псуватися. Одна з причин того, чому команди не в змозі здійснити рефакторинг: вони пишуть недостатньо модульних тестів, тому й бояться, що рефакторинг порушить те, що раніше працювало. Боротьба зі страхом перед змінами є головною метою управління командою, і все це зводиться до дисципліни тестування.”
“Швидкість спадає, а от тиск на команду зростає. Це знецінює одиниці складності. За роздуванням одиниць може ховатися падіння швидкості виконання проєкту.”
“Еталонна історія. Одним зі способів уникнути знецінення є постійне порівняння історій з початковою еталонною, стандартом, за яким будуть оцінюватися інші історії. Памʼятайте, що вхід був нашою первинною еталонною історією, і вона оцінювалася 3 одиницями. Якщо нова історія, наприклад виправити помилку в пункті меню, отримує оцінку 10, то стає зрозуміло, що в хід пішло знецінення.”
“То що таке специфікація? Специфікація, по суті, є тестом.”
“Коли тестування переноситься на кінець, уся відповідальність за затримки падає на плечі спеціалістів із контролю якості.”
“У Scrum клієнта називають власником продукту. Це людина (або група), яка обирає історії, установлює пріоритети та надає своєчасний зворотний зв’язок.”
“Коли цілісна команда ділить між собою один простір, може статися магія.”
“Коли члени команди перебувають у межах одного простору, робота йде рівномірніше.”
“Коли члени команди працюють з дому, то все ж спостерігається значна нестача невербального спілкування. Безтурботні розмови трапляються набагато рідше.”
“програмний проєкт — це марафон, а не спринт чи серія спринтів. Щоб виграти, потрібно правильно розподілити сили. Якщо ви стрибаєте через перешкоди й женете на всіх парах, у вас вичерпається енергія задовго до фінішної прямої.”
“Визначте, скільки годин сну потребує ваш організм, а потім надайте цим годинам найвищий пр��оритет. Сон упродовж цих годин повністю окупиться. Маю правило: перша недоспана година коштує мені дві години денної роботи. Друга недоспана година коштує мені ще чотири години продуктивної роботи. І звичайно, про продуктивність можна забути узагалі, якщо я недоспав три години.”
“на стендап-зустрічах дозволяється говорити лише розробникам. Менеджери та інші співробітники можуть слухати, але втручатися не повинні.”
“Подвійна бухгалтерія. Бухгалтери мають алгоритм дії, винайдений 1000 років тому. І на- зивається він подвійна бухгалтерія». Кожна транзакція, яку вони проводять, вноситься до книги двічі: уперше як кредит на один рахунок, а вдруге як дебет — на інший. Ці рахунки зрештою зливаються в єдиний документ, який називається баланс, де від суми активів віднімається сума боргових зобовʼязань та власного капіталу. Така різниця повинна дорівнювати нулю. Якщо вона не дорівнює нулю, то десь допущено помилку?.”
“Керована тестами розробка — це аналогічна бухгалтерській практика для програмістів. Кожна дія повторюється двічі: спершу пишуть тест, а потім виробничий код, який зможе цей тест пройти. Ці дві дії взаємодоповнюють одна одну, як активи й пасиви. Коли ці дві дії виконуються разом, то зрештою отримуємо нульовий результат: жодний тест не провалено.”
“Ці два напрямки — ведення подвійної бухгалтерії та керована тестами розробка — рівнозначні. Вони обидва виконують ту саму функцію - запобігати помилкам у критично важливих документах, де кожен символ повинен бути правильним.”
“Керовану тестами розробку можна описати трьома простими пра- вилами. 1) Не пишіть готовий код, доки спершу не буде написано тест, який не вдасться пройти саме завдяки відсутності виробничого коду. 2) Не пишіть тестів більше, ніж це необхідно для провалу. Збій під час компіляції також уважається провалом. 3) Не пишіть коду більше, ніж достатньо для проходження тесту, який до цього завершився провалом.”
“Покриття тестами трохи більше за 90 %, імовірно, буде достатнім і справді досяжним.”
“Застереження. Повнота тесту — це показник для команди, а не для менеджерів. Менеджери навряд чи в курсі, що саме він означає. Менеджери не повинні використовувати цей показник як напрямок дій або ціль. Команда має використовувати його виключно для інформування про свою стратегію тестування.”
“Коли у вас є повний набір тестів, ви втрачаєте страх здійснити зміни в коді. Утрачаєте страх очищення коду. Отже, ви таки почистите код. Ви будете тримати систему акуратною та впорядкованою. Ви збережете структуру системи незмінною. Ви не створите масу кодового перегною, яка затягне команду в депресію низької продуктивності та спричинить подальші невдачі. Ось чому ми застосовуємо керовану тестами розробку. Ми практикуємо її, бо вона дає нам сміливість підтримувати код чистим і впорядкованим. Сміливість діяти як професіонали.”
Тренування мозку (promo)
“обмежує всі проєкти й накладає обмеження згідно з правилом хреста. Добре, швидко, дешево, готово. Оберіть будь-які три складники, які вам подобаються. Але четвертий ви подужати не зможете.”
“Agile — це комплекс методів, який допомагає розробникам та менеджерам здійснювати прагматичне управління проєктами.”
“Agile — це насамперед підхід, орієнтований на зворотний звʼязок. Кожен тиждень, день, година та хвилина визначаються результатами попереднього тижня, дня, години та хвилини, і потім уносяться відповідні корективи. Це застосовується як до окремих програмістів, так і до управління всією командою. Без даних важко належно керувати проєктом’”
“Аналіз можна розуміти як розбиття проєкту на структурні елементи (декомпозиція). Або ж як виявлення та розробку вимог. Можна як створення базової моделі даних або обʼєктної моделі тощо…”
“Етап проєктування програмного забезпечення для нас зрозумілі-ший. Він полягає в розділенні проєкту на модулі й створенні інтерфейсів між ними.”
“Аналіз та проєктування не працюють у парі як показники результативності. У них немає однозначних критеріїв завершеності.”
“Спринт — термін, який використовують у Scrum. Мені він не подобається, бо має на увазі, що потрібно мчати стрімголов. Проект із розробки програмного забезпечення — марафон, а хто на марафоні вдається до спринту?”
“Головна мета Agile - позбутися марних надій. Ми практикуємо Agile, щоб знищити надію, перш ніж вона спричинить «смерть» проєкту. Надія вбиває проєкт. Це те, що змушує ко��анду з розробки програмного забезпечення вводити в оману менеджерів щодо її реального просування вперед. Коли менеджер запитує команду: «Як ідуть справи?», то в самому запитанні вже жевріє надія на відповідь «Дуже добре». Надія — дуже поганий спосіб управління програмним проєктом. A Agile — це спосіб забезпечити своєчасну й безперервну дозу холодної, суворої реальності навзамін надії.”
“Менеджери керують програмними проєктами, збираючи дані, а потім ухвалюють на їх основі найкращі рішення з можливих. Agile виробляє дані. Багато даних. Менеджери використовують їх, щоб привести проєкт до найкращого можливого результату.”
“Закон Брукса стверджує: «Додавання робочої сили до проєкту, здача якого затягується, затримує його ще більше». [Brooks, Jr., F. P. 1995 [1975]. The Mythical Man-Month. Reading, MA: Addison-Wesley.]”
“Для цієї книжки я дібрав методи екстремального програмування, оскільки з усіх методологій Agile воно є найкращим, найвизна-ченішим, найповнішим та найменш заплутаним. Практично всі інші процеси Agile є підмножиною або варіацією екстремального програмування.”
“Beck, K. 2000. Extreme Programming Explained: Embrace Change. Boston, MA: Addison- Wesley. Існує й друге видання, датоване 2005 роком, але перше — моє улюблене, і я вважаю саме його кінцевим варіантом.”
“акцент Agile на тестуванні, рефакторингу, простоті дизайну та відгуках клієнтів — це очевидний лікувальний засіб від продукування поганого коду.”
“Ступінь легкості впровадження змін у програмне забезпечення вказує на те, наскільки сама команда заважає створенню ефективного програмного забезпечення. Клієнти, користувачі та менеджери очікують, що програмне забезпечення буде легко змінити, а вартість таких змін буде невеликою та пропорційною.”
“Agile не процес. Agile не тренд. Agile не просто набір правил. Це, найвірогідніше, сукупність прав, очікувань та методів, яка складає основу професійної етики.”
“можу порекомендувати вивчити техніку оцінювання та аналізу програм і проєктів (PERT) [https://en.wikipedia.org/wiki/Program...]”
“Історія користувача - це скорочений опис функцій програми, розказаний з погляду користувача.”
“оцінювання відбувається не за часовими пара-метрами, а за складністю виконання. Одиниці складності історії мають бути лінійними. Картка з оцінкою 2 повинна вимагати приблизно половини зусиль картки з оцінкою 4. Однак лінійність не повинна бути ідеальною.”
“час спланувати першу ітерацію. Перший крок - зустріч, присвячена її плануванню. Ця зустріч повинна тривати одну двадцяту всієї ітерації. Тобто для двотижневої ітерації зустріч має тривати близько пів дня. На зустріч, присвячену плануванню ітерації, має зʼявитися вся команда, тобто програмісти, тестувальники, керівник проєкту, а також зацікавлені сторони. Останні мають попередньо прочитати оцінювані історії та відсортувати їх у порядку цінності для свого бізнесу.”
“Важливо усвідомити, що швидкість не є обовʼязком. Команда не обіцяє виконати 30 одиниць за час ітерації. Вона навіть не обіцяє зробити спробу в цьому напрямку. Це не що інше, як здогадка про те, скільки одиниць за найкращого розвитку подій буде завершено до кінця ітерації. Таке передбачення не дуже точне.”
“квадранти використовуються для розрахунку рентабельності інвестицій (ROI). Це неформальний підхід, і математика тут не потрібна. Зацікавлені сторони просто дивляться на картку й роблять висновки на основі цінності та складності історії.”
“Мета ітерації - генерувати дані для менеджерів.”
“Користувацькі історії — це прості висловлювання, застосовувані нами як нагадування про функції. Ми намагаємося не занотовувати занадто багато подробиць, коли пишемо історію, бо знаємо, що ці деталі, імовірно, зміняться. Подробиці записують пізніше, але у формі приймальних тестів,”
“Історії мають відповідати критеріям якості, закладеним в абревіатурі INVEST.”
“Незалежність (І — Independent). Історії користувачів незалежні одна від одної. Це означає, що їх не потрібно реалізовувати в якомусь конкретному порядку. До прикладу, після входу в систему не потрібно одразу реалізовувати функцію виходу. Це нежорстка вимога, бо цілком можуть існувати історії, які залежать від інших, котрі потребують першочергової реалізації.”
“Придатність для обговорення (N - Negotiable). Це ще одна причина, чому ми не записуємо всі деталі. Ми хочемо, щоб вони стали предметом обговорення розробників та замовників.”
“Цінність (V - Valuable). Цінність історії для замовника повинна бути чітко окресленою й вимірюваною.”
“Рефакторинг ніколи не вважають історією. І архітектуру також. Та й наведення ладу в коді. Історія — це завжди те, що містить у собі цінність для клієнта.”
“історія пройде крізь усі рівні системи. Вона може частково містити трохи графічного інтерфейсу, проміжного програмного забезпечення, баз даних тощо. Сприйміть історію як тонкий вертикальний зріз крізь горизонтальні прошарки системи.”
“Піддається оцінці (Е — Estimable). Користувацька історія повинна бути достатно конкретною, щоб розробники могли її оцінити.”
“Малий обсяг (S — Small). Користувацька історія не повинна бути великою, щоб бути реалізованою одним або кількома розробниками за одну ітерацію.”
“Не слід давати можливість одній історії домінувати в роботі всієї команди протягом цілої ітерації. Ітерація повинна містити приблизно стільки ж історій, скільки розробників є в команді. Якщо в команді 8 розробників, то кожна ітерація повинна містити приблизно від 6 до 12 історій. Однак ви ж не хочете заплутатися у вирішенні цього питання. Це більше рекомендація, аніж правило.”
“Придатність для тестування (Т - Testable). Клієнт повинен мати можливість обрати тести, які підтвердять, що історію завершено.”
“Зазвичай ці тести пишуть спеціалісти з перевірки якості (QA-спеціалісти), вони будуть автоматизовані та використовуватимуться для перевірки того, чи завершено історію.”
“Grenning, J. W. 2002. Planning Poker or how to avoid analysis paralysis while release planning. Доступ за адресою https://wingman-sw.com/articles/plann...”
“Розбиття історій — трохи цікавіше заняття, оскільки вам потрібно дотримуватися критеріїв INVEST. Як простий приклад розбиття історії розглянемо вхід (залогування). Якщо ми побажаємо розділити його на більш дрібні історії, то можна створити такі: вхід без пароля, вхід з однією спробою, дозволити кілька спроб уведення пароля та забули пароль.”
“Метою кожної ітерації є отримання даних шляхом виконання істо-рій. Команда повинна зосереджуватися на історіях, а не на завданнях, які лежать в їхніх межах. Набагато краще зробити 80 % історій, ніж кожну історію на 80 %. Зосередьтеся на доведенні історій до завершення.”
“У менеджерів та ведучих буде спокуса призначати програмістам історії. Та цього слід уникати. Набагато краще дозволити програмістам самим між собою домовлятися.”
“Якщо спеціалісти з контролю якості ще не почали писати автоматизовані приймальні тести, то щойно завершиться зустріч із приводу планування ітерації, уже час починати. Тести для історій, які заплановано виконати серед перших, слід підготувати якнайраніше. Завершені історії не мусять чекати, коли приймальні тести будуть нарешті готові.”
“Написання приймального тесту повинно проходити швидко. Ми очікуємо, що всі вони будуть готові до середини ітерації. Якщо не всі приймальні тести буде створено до середини, то деяким розробникам слід припинити роботу над історіями й почати працювати над приймальними тестами.”
“Якщо спеціалісти з контролю якості продовжують провалювати написання тестів до середини кожної ітерації, то, імовірно, співвідношення інженерів з контролю якості та розробників неправильне.”
“Коли історія пройшла приймальні тести, її можна вважати завершеною.”
“Кожна ітерація закінчується короткою демонстрацією нових історій для зацікавлених сторін. Ця зустріч повинна тривати не більше однієї двох годин, залежно від розміру ітерації.”
“Найкраще, якщо самі зацікавлені сторони перевірять роботу системи, аби розробники не спокушалися можливістю приховувати те, що не працює.”
“Графік швидкості говорить нам про те, наскільки добре керують командою. Графік швидкості буде доволі спотвореним, особливо під час перших ітерацій, оскільки команда ще зʼясовуватиме основи проєкту. Але після кількох ітерацій неточності повинні знизитися до рів-ня, який би дозволив визначити середню швидкість робіт.”
“Ми не розраховуємо, що команда буде прискорюватися або ж уповільнюватися протягом тривалого часу.”
“Спадання швидкості. Якщо графік швидкостей показує стійкий негативний ріст, то найбільш вірогідною причиною є якість коду. Команда, імовірно, застосовує недостатньо рефакторинга, і код починає псуватися. Одна з причин того, чому команди не в змозі здійснити рефакторинг: вони пишуть недостатньо модульних тестів, тому й бояться, що рефакторинг порушить те, що раніше працювало. Боротьба зі страхом перед змінами є головною метою управління командою, і все це зводиться до дисципліни тестування.”
“Швидкість спадає, а от тиск на команду зростає. Це знецінює одиниці складності. За роздуванням одиниць може ховатися падіння швидкості виконання проєкту.”
“Еталонна історія. Одним зі способів уникнути знецінення є постійне порівняння історій з початковою еталонною, стандартом, за яким будуть оцінюватися інші історії. Памʼятайте, що вхід був нашою первинною еталонною історією, і вона оцінювалася 3 одиницями. Якщо нова історія, наприклад виправити помилку в пункті меню, отримує оцінку 10, то стає зрозуміло, що в хід пішло знецінення.”
“То що таке специфікація? Специфікація, по суті, є тестом.”
“Коли тестування переноситься на кінець, уся відповідальність за затримки падає на плечі спеціалістів із контролю якості.”
“У Scrum клієнта називають власником продукту. Це людина (або група), яка обирає історії, установлює пріоритети та надає своєчасний зворотний зв’язок.”
“Коли цілісна команда ділить між собою один простір, може статися магія.”
“Коли члени команди перебувають у межах одного простору, робота йде рівномірніше.”
“Коли члени команди працюють з дому, то все ж спостерігається значна нестача невербального спілкування. Безтурботні розмови трапляються набагато рідше.”
“програмний проєкт — це марафон, а не спринт чи серія спринтів. Щоб виграти, потрібно правильно розподілити сили. Якщо ви стрибаєте через перешкоди й женете на всіх парах, у вас вичерпається енергія задовго до фінішної прямої.”
“Визначте, скільки годин сну потребує ваш організм, а потім надайте цим годинам найвищий пр��оритет. Сон упродовж цих годин повністю окупиться. Маю правило: перша недоспана година коштує мені дві години денної роботи. Друга недоспана година коштує мені ще чотири години продуктивної роботи. І звичайно, про продуктивність можна забути узагалі, якщо я недоспав три години.”
“на стендап-зустрічах дозволяється говорити лише розробникам. Менеджери та інші співробітники можуть слухати, але втручатися не повинні.”
“Подвійна бухгалтерія. Бухгалтери мають алгоритм дії, винайдений 1000 років тому. І на- зивається він подвійна бухгалтерія». Кожна транзакція, яку вони проводять, вноситься до книги двічі: уперше як кредит на один рахунок, а вдруге як дебет — на інший. Ці рахунки зрештою зливаються в єдиний документ, який називається баланс, де від суми активів віднімається сума боргових зобовʼязань та власного капіталу. Така різниця повинна дорівнювати нулю. Якщо вона не дорівнює нулю, то десь допущено помилку?.”
“Керована тестами розробка — це аналогічна бухгалтерській практика для програмістів. Кожна дія повторюється двічі: спершу пишуть тест, а потім виробничий код, який зможе цей тест пройти. Ці дві дії взаємодоповнюють одна одну, як активи й пасиви. Коли ці дві дії виконуються разом, то зрештою отримуємо нульовий результат: жодний тест не провалено.”
“Ці два напрямки — ведення подвійної бухгалтерії та керована тестами розробка — рівнозначні. Вони обидва виконують ту саму функцію - запобігати помилкам у критично важливих документах, де кожен символ повинен бути правильним.”
“Керовану тестами розробку можна описати трьома простими пра- вилами. 1) Не пишіть готовий код, доки спершу не буде написано тест, який не вдасться пройти саме завдяки відсутності виробничого коду. 2) Не пишіть тестів більше, ніж це необхідно для провалу. Збій під час компіляції також уважається провалом. 3) Не пишіть коду більше, ніж достатньо для проходження тесту, який до цього завершився провалом.”
“Покриття тестами трохи більше за 90 %, імовірно, буде достатнім і справді досяжним.”
“Застереження. Повнота тесту — це показник для команди, а не для менеджерів. Менеджери навряд чи в курсі, що саме він означає. Менеджери не повинні використовувати цей показник як напрямок дій або ціль. Команда має використовувати його виключно для інформування про свою стратегію тестування.”
“Коли у вас є повний набір тестів, ви втрачаєте страх здійснити зміни в коді. Утрачаєте страх очищення коду. Отже, ви таки почистите код. Ви будете тримати систему акуратною та впорядкованою. Ви збережете структуру системи незмінною. Ви не створите масу кодового перегною, яка затягне команду в депресію низької продуктивності та спричинить подальші невдачі. Ось чому ми застосовуємо керовану тестами розробку. Ми практикуємо її, бо вона дає нам сміливість підтримувати код чистим і впорядкованим. Сміливість діяти як професіонали.”
Тренування мозку (promo)
February 28, 2020
Ótima leitura inclusive para quem nunca teve experiência com Agile.
Não é uma leitura totalmente técnica
Não é uma leitura totalmente técnica
January 20, 2021
Classic Uncle Bob. Lots of memories, lots of programming history, lots of subjective opinions. This book has many drawbacks but it's worth reading in the end.
What I liked:
- all these stories about punched cards and programming in the 60's and 70's are always interesting :)
- the whole concept of reminding what the term Agile actually means is a great idea. I totally agree that we have a big problem with entire path of Agile certification and Agile coaching by non-technical people. So many technical problems are just swept under the rug.
- chapter number 7 by Sandro Mancuso - in my opinion this is the best part of the book
What I didn't like:
- it's really short and some topics are just briefly touched
- this is the fifth book of Robert Martin I've read. I feel like the main message of Clean Agile is simply repetition of statements from previous books - especially from Agile Software Development and Clean Coder.
- I'm a fan of Agile, but I'm also aware of many challenges related to this concept (e.g. user stories vs domain knowledge; long-term technical vision / architecture vs sprints and "flying requirements"). This in not a position where you can find answers for deeper problems :)
What I liked:
- all these stories about punched cards and programming in the 60's and 70's are always interesting :)
- the whole concept of reminding what the term Agile actually means is a great idea. I totally agree that we have a big problem with entire path of Agile certification and Agile coaching by non-technical people. So many technical problems are just swept under the rug.
- chapter number 7 by Sandro Mancuso - in my opinion this is the best part of the book
What I didn't like:
- it's really short and some topics are just briefly touched
- this is the fifth book of Robert Martin I've read. I feel like the main message of Clean Agile is simply repetition of statements from previous books - especially from Agile Software Development and Clean Coder.
- I'm a fan of Agile, but I'm also aware of many challenges related to this concept (e.g. user stories vs domain knowledge; long-term technical vision / architecture vs sprints and "flying requirements"). This in not a position where you can find answers for deeper problems :)
Displaying 1 - 30 of 154 reviews