Менше сумнівів

Не знаю як ви, а я боюся своїх сумнівів. Вони отруюють життя, забирають час і мотивацію. Тому я ненавиджу сумніватися! 

 

У так званому Lean Development навіть офіційно затверджено Принцип №4: 

Відкладай зобов'язання (Defer commitment), що означає: 
Приймай рішення якнайпізніше! 
Див. http://www.allaboutagile.com/lean-principles-4-defer-commitment/ 


Чому не вирішувати раніше, адже це могло б прискорити весь процес? 
Чим менше невідомих у рівнянні, тобто не прийнятих рішень, тим швидше можна розв'язати задачу. 

Суть цього принципу в тому, що із часом все зміниться, додасться нова інформація, і або вже не буде, про що думати, або рішення буде прийняти простіше. 

Але як не відкладай, після рішення гарантовано прийде нова інформація, а за нею - сумніви у правильності рішення. 

Зменшити сумніви дуже допомагає візуалізація наявної інформації. Бо часто ми боїмося, що, скажімо, рішення не сподобається іншим, але просто не хочемо собі зізнатися, чому саме.

Причини всіх рішень

Кожному моменту я звик шукати пояснення.  Зазвичай, я доходжу до якоїсь межі доцільності, глибше якої, я вважаю, вже нічого не можна достеменно з'ясувати.

Ці найглибші, з доступних, пояснення я відношу до певних категорій. Якщо я не можу точно виявити категорію, значить я копаю далі. Але я можу копати далі і категоризовану причину. 
Отже, причини різних рішень я розділяю на наступні категорії:

•      Фізичні чинники. Сюди входять всі ресурсні обмеження. Коли для того, щоб зробити інакше(ліпше) не вистачило грошей, людей чи технічних можливостей.

•      Політичні чинники. До цієї категорії я відношу рішення, основані на людських взаєминах. Як то "Головна компанія наказала нам використовувати цей сервіс" чи "Ми не можемо робити цю задачу, бо нас за це покарають". Головна їхня ознака - це емоційне слово, що не має сенсу поза людським контекстом, як то "боятися", "ненавидіти", "карати", "любити", "обожнювати"; чи слово, що відображає людські взаємини, ієрархію, наприклад "наказувати", "підлягати", "розпоряджатися", тощо.

•      Історичні чинники можуть мати політичний чи фізичний характер, але це те, що ґрунтується не на теперішній дійсності, а на минулій, коли ті фізичні та політичні впливи мали місце.

І от останнім часом мені стало здаватися, що мене оточили політичні та політично-історичні чинники, причому не моєї політики. Гнітюче відчуття, що тебе закручено в чужих тенетах. Ну і от я звільнився. Привітайте мене!

"5 hours a day" keeps pressure away

A common question raised by customer-side management:

• How to control software engineers? 
• How I, as a customer who pays huge bags of cash per hour to this hippies, can really know that they are not cheating me watching youtube half a day?

But even if the question is not asked explicitly, does not mean nobody has doubts alike. 

I worked in various environments. Let me review the most common solutions and their pros and cons.

Tester's mental "try ... catch"

Once this blog post http://www.inspiredtester.com/inspired-tester-blog/process-metrics-and-the-impact-of-context (and maybe a little bit of Jerry Weinberg's ideas) inspired me to this thoughts.




People like their "status Quo". They don't like to act. Every their action is forced by change. The change may be in outside, in circumstances; and it may be in themself. Changing the way one acts too is a reaction to different changes one experiences.

Applying this to the Software Testing, an experienced user becomes a tester, when they react not directly to external changes, but to the internal feelings induced by external changes. Establishing some kind of "try - catch" block for distractions in their brain. Instead of (or additionally to) just shouting out loud that "This piece of software does not work!", the tester asks themself: "What causes my such a reaction?" and puts the answer to the Bug Report title.

Agility of "agile"

As for me, currently a "new renaissance" of Agile (with capital "A") followers is going on. With their not getting the spirit of agile manifesto, but just following "best" practices and rules from some guide books, not regarding the reality, context and consequences of their deeds. (It may be connected to the new generation of IT employees stepping on the scene.)

That's why it's great that there appear new posts on this subject, trying to educate people about the difference between "agile" and "Agile".

Here is a post I liked recently from Yegor Bugayenko: 12 Mistakes in Agile Manifesto.

Гнучкість "гнучкості"

Мені здається, зараз відбувається якесь "нове відродження" адептів Agile (з великої літери) - людей, що не розуміють дух agile manifesto, а лише намагаються слідувати книжковим правилам без огляду на дійсність та результати своїх дій. (Це може бути пов’язано із черговою великою хвилею "нових айтішників".)

І от як раз нагодився текст Єгора Бугаєнка: 12 помилок Agile маніфеста (12 Mistakes in Agile Manifesto).

В житті цих помилок, звісно ж, не 12, бо кожен із постулатів Agile Маніфеста може мати безліч неправильних інтерпретацій :-)

Питання на співбесіду

Приймаючи участь у співбесідах, я рідко дотримуюся свого плану, адже, на мою думку, співбесіда має лишатися "спів-" - тобто взаємною - "бесідою" - тобто діалогом рівних людей, що мають якісь спільні інтереси. Найбільше мене тішить, коли на співбесіді я дізнаюся про щось нове й цікаве.

Ось мій особистий список того, що я хочу дізнатися у кандидата, безвідносно його професійного рівня. Просто відповіді провідного "сіньора" будуть більш фундаментальними та розлогими, а молодшого "джуніора" - короткими, наприклад "Не знаю." :-)