アジャイルマニュフェスト：ソフトウェアアーキテクトの視点
まず、最も重要なのは、アーキテクトが間違っている可能性があるということです。これは、私が詳細な事前技術設計を作成し、Sprintを改良中に開発チームに提示した後に起こりました。私が考えていなかったケースや考慮に入れなかったケースに関連する質問がありました。ほとんどのケースで、初期設計は不完全または非実用的であり、追加の作業が必要であることが判明しました。 大きな事前設計により、チームメンバーの創造性と自律性が制限されます。これは、チームメンバーが既に付与されているレシピに従う必要があるためです。心理学的な観点からは、著者でさえも、後になってそれを変更する方向に傾いたり、変更に消極的になるかもしれません。その欠陥を認めるのではなく、正しいことを証明しようとするかもしれません。 アーキテクトは、正確な詳細設計を事前に提供するのに苦労するため、チームのボトルネックにもなります。常に事前設計を提供
分散型アジャイルチームによる作業から学んだこと
原文(投稿日：2019/05/09)へのリンク 分散型チームでは、同僚との対面によるコミュニケーションが頻繁に行えないことが、コミュニケーションの成立を通常よりも難しくしている、とABN AMRO BankのスクラムマスタであるShabi Shafei氏は言う。氏は、アムステルダムで開催された"Agile, Testing, DevOps Showcase 2019"において、分散型チームを優れたアジャイルチームへと転換させる方法について講演した。 分散型チームが直面する大きな課題は、チームメンバ間の物理的な距離によるものだ、とShafei氏は言う。"同僚と定期的に、物理的に会えなければ、信頼やオーナシップ意識を築くのは難しい"、とする氏は、さらに、分散型チームでは文化の違いがより顕著になる、とも述べている。 Shafei氏が提案するのは、互いに協力を望む規範の確立に注力することである。有
テスト駆動開発：実はそれは設計技術です
テスト駆動開発（TDD）は、より優れたソフトウェアを持続的に早く提供するための確立された手法です。TDDは単純な考えに基づいている。製品コードを書く前に失敗するテストを書くことです。新しい行動が必要ですか？失敗するテストを書いてください。しかし、この一見単純な考えをうまく実行するには、スキルと判断が必要です。 TDDは本当に設計のためのテクニックです。TDDの基礎は、小規模なテストを使用してボトムアップを早急に設計することであり、システムへの信頼を構築しながら迅速に何らかの価値を得ることです。よりよい名前はテスト駆動設計かもしれません。 設計方法としては、集中と単純さです。目標は、開発者が価値を提供する上で不要な余分なコードを書くことを防ぐことです。問題を解決するのに必要最小限のコードを書くことです。 多くの記事がTDDを行うことのすべての利点を誇りにしています。そして多くの技術会議の講演
SamsungのアジャイルとリーンUXへの旅
原文(投稿日：2019/04/11)へのリンク Samsungは、チーム主導のアジャイル移行と、それに続く文化主導のアジャイル移行の適用を通じて、現実のユーザと価値のあるプロダクトにチームを集中させることに成功した。同社のシニアUXデザイナであるJaesung Jo氏は、Lean and Agile ME Summit 2019で行った講演で、製品開発全体を通してチーム主導のユーザーリサーチを実施するための、ペルソナの作成と利用について語った。 Samsungはいくつかのアジャイル移行アプローチを試みた、とJo氏は言う。2010年、同社はまず、プロセス主導の移行アプローチに着手した。それがアジャイル移行の最速の方法と思われたからだ。コンサルティング会社の支援を受け、会社を変えるためのアジャイルプロセスと構造をデザインした。しかし長続きはしなかった。人的リソースと組織構造にタッチしていなかっ
React Native開発チームが開発者の苦情調査を実施
原文(投稿日：2019/03/15)へのリンク React Nativeチームは先頃，React Native開発者を対象に，"あなたがReact Nativeで気に入らない部分は何ですか？"という，ひとつの質問の調査を行った。最初の不満として圧倒的に多かったのは，デバッグを含む開発者エクスペリエンスだった。コミュニティへの対応やドキュメントなども，不満な部分として際立っていた。多くの開発者が，React Nativeのアプリケーションプログラミングインターフェース(API)を拡張して，SVGでの開発などで頻繁に発生するユースケースに対応することを求めていた。ネイティブ風アプリケーションのためのシームレスでクロスプラットフォームな開発ツールという，React Nativeの目標がまだ実現できていないのではないか，と指摘する声もあった。 回答した開発者の大多数は，アップグレードに多くの労力が
効果的なモブプログラミングパターン
原文(投稿日：2019/02/18)へのリンク FlexBusのテスタで，テストに関するブログを執筆しているLisi Hocke氏は先日，ブラチスバラで開催されたTesting Unitedカンファレンスで講演し，部分的にモブプログラミングを使用した"全チームアプローチ(whole-team-approach)"をテストに適用することが，協力的な開発環境の構築に有用であった自身の経験を語った。その中でHocke氏は，ペアリングのドライバとナビゲータの関係をより規模の大きなモブへと拡大することによって，最大限の積極的な参加を実現した方法について説明した。"Mob Programming Guidebook"の著者であるMaaret Pyhäjärvi氏と，"Pragmatic Unit Testing in Java"の著者で，Robert Martin氏の"esteemed Clean C
マネージャの視点からのアジャイルの実践
原文(投稿日：2018/10/20)へのリンク 子供の頃から私は、成功するためには個人として一番にならなければならないと教えられてきました。このことはほとんど全ての学校に当てはまり、楽器を演奏するときや、評価の要素があるところにならどこにでも現れました。私が他人と協調できるかどうか、妥協点を探せるかどうか、他人に行動を起こさせるように鼓舞できるかどうかに興味がある人などほとんどいませんでした。このことに特に注意を払う人もいませんでした。私たちは協調することも、互いに助け合うことも教わりません。これによって格付けされることありません。それはソフトな特性、育ち、経験した境遇の結果として、自然発生的に起こるのです。 しかしながら、成功の裏にチームがいることの方が多い しかしながら、現実が示しているように、成功の裏には個人よりチームがいることの方が多いでしょう。私はスポーツが好きなので、次の例が最
反省会での心理的安全性
インシデントが発生すると感情が前面で出てくる。学習プロセスの中で非難なしの心理的に安全な反省会は重要だ。反省会は穏やかに行い、なるべく部外者が参加し、非難なしで皆に話す機会を与えるべきだ。本当に何が起きたのかを明確に理解するまでは、インシデントの分析を開始してはならない。 AdaptavistでDevOps部門を率いているMatt Saunders氏は非難なしの反省会の心理的安全性についてAtlassian Summit Europe 2018で話をした。InfoQはこのカンファレンスの内容を記事やインタビューで取り上げている。 InfoQは氏にインタビューし、非難なしの反省会について、それが、アジャイルの振り返りとどう違うのか、感情への対処の仕方、反省会で皆が安全さを感じするためにできること、効果的な反省会を開催する方法について話を聞いた。 InfoQ: どんな場合に非難なしの反省会をす
Googleが解説 - 他社のSRE実践はなぜ誤りなのか
GoogleのCRE(Customer Reliability Engineer)であるStephen Thorne氏が先日のDevOps Enterprise Summit Londonで講演し、SRE(Site Reliability Engineering)とは何か、その基本的な前提とメリットを理解できていない組織がいかに多いか、などについて解説した[スライドのPDF]。氏がこれまでに他の組織で見たおもな誤解は、早期の障害検出に重点を置いたSLO(Service Level Objective)や、あるいは過去のインシデントの金銭的保証に使用するSLA(Service Level Agreement)との混同、エラー予算を執行しない、SREチームの活動の少なくとも50パーセントをシステムやツールの改善に費やさず、“消防活動”という名の運用上の苦役に没頭させる、といったものだ。 SLO
LinkedInのカオスエンジニアリング - "LinkedOut"障害注入テストフレームワーク
LinkedIn Engineeringチームが先日、自らの“LinkedOut”障害注入テストフレームワークについて、その詳細を説明した。このフレームワークは、アプリケーションとサービスのレジリエンスに関する仮説の生成をサポートし、LinkedIn LiX A/Bテストフレームワークまたはクッキー内のデータを通じて、特定のリクエストへの障害の注入を可能にする。テスト可能な障害シナリオはエラー、遅延、タイムアウトなどである。このLinkedOutプロジェクトは、LinkedInのすべてのチームがレジリエンスエンジニアリング活動に取り組む、“Waterbear”活動の一環として運用されている。 サイト信頼性を担当するシニアエンジニアのLogan Rosen氏は先頃、LinkedIn Engineeringブログに、“LinkedOut: A Request-Level Failure Inj
幸福な文化がハイパフォーマンスを実現する
英国の放送局ITVで共通プラットフォームチームを率いるTom Clark氏が2月のDOXLONで講演し、自主性(autonomy)と熟達(mastery)と目的(purpose)に関するDan Pink氏の原理に基づいて、英国最大のメディア企業のひとつであるITVで幸福感と意欲に満ちたチームを作り上げた自身の経験を語った。講演で氏は、ハイパフォーマンスは幸福なチームを作り上げることの副作用である、という仮説を提案し、その立証を試みた。Way to GoのCEOで、2016年の書籍“An Everyone Culture: Becoming a Deliberately Developmental Organization”にも寄稿しているAndy Flemming氏は、先日のAgile Uprising Podcastとのインタビューで、個人の学習や成長、幸福を重視する文化の構築によって企
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
The Importance of Metrics to Agile Teams
JVMの比較を目的とする新しいパフォーマンスベンチマーク”Renaissance”
アジャイル作業のスケールアップアプローチはなぜ失敗するのか？
W3C、没入型ハードウェアで直接WebインタラクションのためのWebXRドラフト仕様を公開
なぜアーキテクチャ図を必要とするのか？
アジャイル第二の波: アジャイルマインドセットに生きる
リモートチームでアジャイルになる
.NETの派生を理解する
アプリケーションが必要なすべてのデータに接続できるMicrosoft Graph