開発手法の話

以下の記事を読んで思ったこと。

管理部門的にはウォータフォールのが管理・把握しやすいから推進したいだろうけど、現場的にはアジャイル的な進め方に寄ってきてるのが現状かな。
クライアントの要請もあるし、競合他社もアジャイルな進め方(実際にやってるかどうかはおいといて)だし、時代の要請ってのはまさにそんなかんじがする。
アジャイルなプロジェクトを管理部門として管理する方法論があると組織全体としてはうれしいのかな。現場から管理部門への報告の手間が増えるのは避けたいけど。

あと、 ウォーターフォールは分業できるけど、アジャイルは分業が難しいと思う。
「企画・販売」「設計・開発」「保守・運用」といったサービスの全工程に携わるメンバーがひとつのプロジェクトチームにならないと効果がでない。 
カタチだけではなく、チーム形成時点での各メンバーが価値感を共有しないと効果がない。ありがちなのは、各工程が部分最適を第一優先にしてしまうケース。プロジェクトに参加するメンバーの所属する組織への説明(エクスキューズ?)が重要だと思う。
あと、できれば複数案件の掛け持ちも避けたいけど、さずがにムズいかな……

開発手法は教科書通りでは、上手くいかないのは昔から。結局のところ、時代や案件に即した進め方を適用して、ときにはアジャストしてやっていくしかないかなあと。

なんだかんだで利用者に役立つシステムを提供し続けて、それに見合う対価を得ることができれば、どんな方法でもいいんだけども。

One clap, two clap, three clap, forty?

By clapping more or less, you can signal to us which stories really stand out.