PDDの原則-パニック主導の開発

こんにちは、Habr!親愛なる読者の皆様、これはマウロ・フレッツァによる素晴らしい記事の翻訳ですそれを楽しんで、開発方法論の現在のトレンドを常に把握していただければ幸いです。



画像


アジャイルファミリーの開発手法の成功の波の後、時の試練に耐えた人はほとんどいません。しかし、それらの中には1つの特別な手法があります。PDDパニック駆動型開発-パニックによる開発です。



この手法は、アジャイル開発手法の基本的な信条を共有していますが、チームの速度を低下させるだけの不必要な式典や技術的負荷がありません。この方法論の原則を詳しく見てみましょう。



タスクが新しいほど、優先度が高くなります



スプリントの途中で新しいタスクが発生するとすぐに、その優先順位は以前に計画されたすべての作業よりも高くなります。結局のところ、新しいものはすべて常により良く、より重要です。一般に、この点はアジャイル手法の基本原則に含める必要があります。



顧客に価値を提供することに重点を置くことは、チームが以前に計画された作業を脇に置き、新しい機能を処理する必要があることを示唆しています。



結果に必要なだけのコードを記述します



開発者はコードを書くことで生計を立てています。エラーはコードによってのみ修正できます。デザインとUXについて議論することは、開発を遅らせるだけです。したがって、これを行います:ソリューションを作成し、修正が機能していることを確認します。すべて問題がなければ、問題は解決します。さらに進んでみましょう。



急いでテストしないでください



修正が実装された後、テストは保留中のタスクとしてスケジュールする必要があります。もちろん、テストは便利ですが、やりすぎないでください。あなたは後でそれらの世話をすることができます。チケットを作成し、バックログにアップロードします。機能を確認するために、手動テストを行うことはかなり可能です。



あなたの感覚を信頼してください



プログラミングは芸術です。本能と直感はあらゆる芸術の不可欠な部分です。心の声に耳を傾けて。解決策を書いてください。より大胆に展開します。幸運は勇敢にのみ微笑む。



プロセスはあなたに適応する必要があります



ソフトウェアの開発、テスト、リリースのプロセスは、単なる一連の規則とルールです。彼らは石に設定されていません。重要な修正には柔軟性が必要です。スピードを上げるために、チームのニーズに合わせてプロセスが変更されることが非常に期待されています。



すべてはマネージャーから来ます



チームマネージャーは、開発の問題について発言する権限を与えられています。すべてのリファクタリングとグッドプラクティスのすべての順守は、ビジネスニーズによって上書きされる可能性があります。もちろん、エンジニアは意見を述べることができますが、最終的には上から伝えられたニーズに対応する必要があります。



結論



PDDは、あらゆるプロジェクトのチームワークの速度を可能な限り短い時間で急速に向上させる手法です。



これは世界中の企業で使用されており、柔軟で妥協のないプログラミングの基盤となっています。



All Articles