1月上旬に、私は今年新しい作業方法の導入について書いた（ 翻訳 ）。 個々の開発者を3人のチーム（2人のプログラマとデザイナー）にまとめることにしました。 チームの構成は2か月間変更されません。 各2か月のモジュールは、それぞれ2週間の4つの連続した反復に分割されます。 繰り返しごとにタスクのリストを減らし、厳しい期限を厳守し、製品を改善するという目標を設定しました。
何から来たの？
2月が終わり、3月が来ました。つまり、新しい方法論に従って、最初の2か月の作業の在庫を取ることができます。 それは何が原因ですか？
作業方法の変更はうまくいきました。 1月と2月は、長い間2つの最も生産的な月でした。 すべてがスムーズであったわけではないという事実にもかかわらず、いくつかの調整を行う必要がありましたが、一般に、この変更は正しい動きであると考えました。
結果
これらの2か月で完了したタスクの一部を以下に示します。
- ハイライズ：ハイライズでの「イベントの流れ」のリサイクル
- HIGHRISE：検索から取引またはユースケースレコードへの直接ジャンプの追加
- HIGHRISE：企業データフェデレーション機能の追加
- HIGHRISE：メール通知、毎日のレビュー、ドロップボックスのvCard情報
- BASECAMP： HTML、コメント、タスクリスト、およびファイルを含む電子メールのデザイン更新
- BASECAMP：電子メールを介したメッセージの送信
- BASECAMP：トークページの再設計
- BASECAMP：タスクレターへの応答がコメントとして追加されます。
- CAMPFIRE： Twitterチャットメッセージのフォーマット
- CAMPFIRE：チャットで画像をプレビュー、チャット履歴のデザインを変更、チャットにブックマークを追加
- LAUNCHPAD：プロジェクトとメインページ間のナビゲーションの改善
- 37id：新しいヘルプセクション
- 回答： 37singnals Answersを開始しました
さらに、多くのバグ修正、小さな更新、インフラストラクチャの改善、設計、コンテンツがありました。
私たちは何を学びましたか？
私たちは多くを学びました。 以下に、この2か月で学ばなければならなかったレッスンの一部を示します。 もちろん、まだ多くのことを学ぶ必要がありますが、すでにこれにより、次のモジュールをさらに成功させることができます。
レッスン：インターフェースから始める
インターフェースを使用して開発を開始する必要があると考えているため、反復の最初の週である月曜日、水曜日、金曜日に、デザイナーがメインタスクのインターフェースソリューションを開発し、プログラマーが小さなタスクと関連するタスクを実行することを決定しましたバグ修正。 したがって、デザインの準備が整うのを待つ必要はありません。 2週間の反復の条件では、誰かのステップが自分のタスクを開始するのを待つ時間はありません。
レッスン：準備ができたら展開する
作業結果はすぐにリリースしてください。 最初のイテレーションでは、すべての更新を展開するために、先週の金曜日まで待機しようとしました。 これは、不必要な問題とストレスにつながりました。 その後、準備ができ次第、更新プログラムの展開を進めることにしました。
レッスン：金曜日を待つな
金曜日にアップデートを公開するのはひどいです。 チームがタスクを完了するための最大時間を確保するために、月曜日から金曜日にタスクをスケジュールし、作成したソリューションを展開しました。 しかし、見逃された問題のために、週末に仕事をしなければならなかったことが判明しました。 全然好きではありませんでした。 金曜日の代わりに、木曜日にソリューションのリリースを開始しました。これにより、予期せぬ問題をフルタイムで解決できました。
レッスン：タスクをできるだけ早く修正する
2週間のイテレーションでは、最初の週の終わりまでに目標と目標を正確に定義する必要があります。 タスクの複雑さを評価する際のエラーのために、何度も緊張した作業環境で自分自身を見つけなければなりませんでした。 2週間の反復で、第2月曜日と次の水曜日にタスクのリストを修正することにしました。 必要に応じて、タスクのリストをトリミングします。 睡眠や理性ではなく、仕事の一部を放棄する準備ができています。 頻繁に「夜のマラソン」、タスクを完了するために英雄的である必要性は悪い兆候です。 枯渇は反復に分割されません。 はい、2週間ごとに反復のための新しい作業計画が作成されますが、疲労は次から次へと移動します。 タスクのリストの調整と削減は、職場での「燃焼」に対処するのに役立ちます。
レッスン：1、2、3-最初からしっかりと決める
実験的に、反復の長さを変更することが理にかなっていることが判明しました。 実験は、2か月のモジュールの最後の3週間で行われました。 今後のプロジェクトの1つでは、この決定は合理的でしたが、別のプロジェクトに過失と時間の超過が確実に加わりました。 余分な1週間で、「明日やるよ」または「来週は大事にします」と言うことができます。 これらの2つのフレーズは、問題が発生することをすでに示しています。 仕事の納期を明確に理解しないと（そして、2週間の期間は3週間よりもずっと明確に感じられます）、目標はぼやけ、タスクの遂行はバックグラウンドに追いやられます。 次回は、1週間、2週間、3週間で反復を試みますが、反復の長さは事前に決定する必要があります。 2週間タスクをスケジュールしてから、反復を延長することはできません。 開発チームはすぐに、「これは毎週の繰り返しです」、「これは2週間の繰り返しです」などと言わなければなりません。
次は？
昨日、3月1日に新しい2か月モジュールが始まりました。 年の初めから次の2か月に得た知識を適用できることを嬉しく思います。 5月にレポートを待ちます。